Talk:VO Portal Policy
From JSPGwiki
| Table of contents |
Jan 23 2009 JSPG Meeting Notes
Changed the names for the different portal classes. Need a good name for the first type of portal. One-click portal?
Clarified definition of pseudonymous user and strongly identified users.
Clarified policy for data persistence.
--Jim Basney 23 Jan 2009
Feedback received, for discussion at May 2009 JSPG meeting
Ursula Epting (Karlsruhe):
- 1.1 Robot "... Agent that perform" -> performs
- 1.1 Robot Certificate "issues" -> issued
- 1.1 Secure Hardware Token, 4th line: "equivalent or stronger., and" remove dot
[JSPG response: Done.]
Infrastructure Policy Group (meeting at OGF25, Catania) received an EGEE Portal Policy document. Is this public? Steven Newhouse subsequently explained that this referred to our draft policy document.
Discussion at 11 March GDB: What about ATLAS production work? Kors Bos should use a robot certificate, not his personal certificate. Is this a "portal" case?
[JSPG response: This would qualify indeed as a Data Management portal, and it would be highly appropriate if the system was made to be compliant with the provisions stated, to prevent things like what happened in March 2009.]
Jeff Templon (NIKHEF): Job Management Portal is really the same as Multi-User Pilot Jobs. The policy should just refer to that one.
[JSPG response: The Job Managment portal applies to systems like Genius, where the Grid sees jobs from individual users and does not see the portal as such. This is different from the MUPJ use case, where, the Grid initially sees a single identity, namely of the job management system, and the user identity is revealed only within the site.]
Ruth Pordes (OSG) - GDB 11 March: There will be no OSG specific policy here and we will ask for a variance. LHC VOs will be covered at the experiment level by the WLCG policy, but other VOs will not have such a policy applied.
--David kelsey 15:10, 11 May 2009 (BST)
May 15 2009 JSPG Meeting Notes
Ursula's changes proposed above have been incorporated. Otherwise no changes since our January meeting.
EGEE Portal Policy document is more focused on accounting / resource allocation portals. Steven and DavidG agree the documents are compatible.
The group drafted responses to comments above.
The GDB has seen this policy, but otherwise it has not yet gone out for wide comment.
Portals, pilot job frameworks, workload management systems, etc., form a wider class of systems that could have a general policy applied. For now we have separate policies for portals and pilot jobs, and no policy for workload management systems. This could be revisited.
A portal may provide services that fall into multiple classifications. In "Portal Classes" section, added a clarifying paragraph about it.
If a portal doesn't "fit" any of the classifications, then the "Job Management Portal" case applies.
Do we retain the requirement for robot certificate private keys held on hardware tokens?
- Earlier this week EUGridPMA adopted a definition of robot certificates that does not require hardware tokens.
- TeraGrid is unlikely to require hardware tokens.
- The text on Secure Hardware Tokens is very long and technical. Can we drop it?
- DavidG replaced it with the OID reference to EUGridPMA. Is this better?
- We have removed the requirement for a hardware-token-based robot and replaced it with "A Grid may mandate the use of a Secure Robot."
This policy is complete and ready for wider consultation.
--Jim Basney 15 May 2009
Changes between Version 3 beta 1 and V3.1
- All previous feedback addressed.
- New term "Secured robot" defined. This means a Robot whose private key is generated and stored on a secure hardware token.
- The text describing a secure hardware token has been removed. This now just refers to the IGTF definition.
- Grids can now decide whether to require Robots or Secured Robots.
- Better description of the handling of portals which cannot easily be classified.
--David kelsey 15:58, 21 May 2009 (BST)
Feedback received on version 3.1, 15 May 2009
Oscar Oliver (PIC, Spain): Do you think this will be the EGI portal policy (or the base for)? Which authority will be in charge for classifying and checking classification of portals? Or in others words ... if a VO is using a portal that does not follow those policies: who will notice and who will enforce corrections or pick actions against that vo portal?
[JSPG response: We plan to hand over all JSPG policies to EGI before4 the end of EGEE-III. We do hope that EGI will adopt this policy. The question of which body will implement and enforce any policy is a matter for the Grid in question. It could, for example, be handled by the NGI in which the portal is located, with either the NGI operations or the NGI operational security teams taking the lead. Many other solutions are also possible.]
Stefan Lueders (CERN):
- Section 2: Why 1 000 000 seconds ? "The Portal must not persistently store passwords or private keys for its end-users that can be used to authenticate to the Grid past 1 million seconds."
[JSPG response: 1 million seconds is the maxiumu lifetime used by IGTF for "short-lived" credentials. It is one (rather arbitrary) definition of something short-lived. Added a phrase to say this.]
- Section 3.1 P4: Is the port really useful?
[JSPG response: It may be used in tracking the remote user on a shared machine.]
- Section 3.2 P1: Replace "and" by "or": "The Portal may offer services to Pseudonymous, Identified >>OR<< Strongly Identified Web Users."
[JSPG response: Agreed.]
- Section 3.2 P4: Be more specific? (e.g. IP, name users, emails, certificate...)
[JSPG response: We decided it was best not to be specific. "Relevant" should be enough.]
- Section 3.3 P3: ditto.
[JSPG response: See above. We also added a sentence to say that relevant authentication info must be kept.]
- Section 3.3 P4: Rephrase. In particular, "...as long as authentication is possible." sounds strange... Do you mean, contact information should exist as long as a web users is registered ?
[JSPG response: Agreed. Reworded.]
Gergely Sipos (SZTAKI, Hungary):
I am happy to see this kind of categorization of portals. I agree with it. I have a few questions/remarks though and would appreciate if the authors could answer these to me.
- "Pseudonymous Web User: a verifiably-human Web User that provides authenticated non-identifying information to the Portal when invoking functionality." I do not understand what the definition of this type of user means. Could you clarify it?
[JSPG response: Added definition of "verifiably-human" to section 1 definition of pseudonymous. See discussion between Fred and David below.]
- In section 3.1: "The Portal must use a Robot Certificate to interact with the Grid." The term "Robot Certificate" is not defined in the document and no reference to other documents is given where a definition could be found. AFASIK only the Italian and the Dutch CA is able to issue robot certificates, so in Hungary, despite we would like to add such certificates into some of our portals we cannot. When and what body will force all the CAs to issue this type of certificates?
[JSPG response: Robot Certificates are defined in section 1. Expanded to include references to documents - see David G comments below.]
- In section 2 the following is written: "The Portal must keep audit logs for all interactions with the Grid." What does "audit log" mean? Is it specified what information must be in such a log and what medium should be used by the portal to store the logs?
[JSPG response: We will add a reference to the Traceability and Logging policy. Quoting from that document ... The aim is to be able to answer the basic questions who, what, where, and when concerning any incident. This requires retaining all relevant information, including timestamps and the digital identity of the user, sufficient to identify, for each service instance, and for every security event including at least the following: connect, authenticate, authorize (including identity changes) and disconnect.]
Frederic Schaer (IN2P3) and David Groep (NIKHEF) discussion of Gergely's questions above:
- Comment 1. Fred: Does this mean some kind of capcha verification is used? David: A capcha would certainly do, but also a one-time email address check on a non-authenticated email (gmail, hotmail or so) would suffice. Or (I would say) if you know inside your constituency that one particular IP address is used for a public login station in a library or so, for library walk-ins, all traffic from that box will be human. The idea is to prevent 'automated' use of the thing (which would overload the resources) and prevent it from being used 'in the back' of another service where trivial programming errors can cause DoS-like behaviour.
- Comment 2. Fred: I'm not sure anybody can force any CA... would people then be forced to use the "default" CA (GRID-FR or CERN)? David: The EUGridPMA has been pushing the member CAs along to get more support for robot certs. These are currently available form the UK, IT, NL and soon from CZ, and boiler-plate text is available for all other CAs to make also their policies RobotReady(TM).
Formally, a Robot cert is today defined as a certificate that complies with the 1SCPs 1.2.840.113612.5.2.3.1.1 "Private Key Protection: Secure Hardware Token" and 1.2.840.113612.5.2.3.3.1 "Entity is a non-human automated client or robot" documented at http://www.eugridpma.org/guidelines/1scp/1SCP-private-key-hardwaretoken-1.1.pdf and http://www.eugridpma.org/guidelines/1scp/1SCP-certtype-robot-0.1.pdf
Please do ask your local CA for a robot cert, and if they cannot supply them yet, ask when these will be available. At the moment, GRID-FR is not yet able to issue these (although they seem to be positive about them). I'm not sure they are on the CERN map (and anyway the target population for robot certs at CERN may be rather small). If it really takes a long time for many national CAs to come along, the policy should maybe be re-worded to allow for a transition.
--David kelsey 19:13, 18 Jun 2009 (BST)
