Talk:Virtual Organisation Membership Management Policy
From JSPGwiki
Please sign your posts (http://en.wikipedia.org/wiki/Wikipedia:Sign_your_posts_on_talk_pages).
| Table of contents |
Changes Between 2.7 and 3.1
- Removed "Site responsibilities & requirement" section, to focus this policy on VO responsibilities.
- Sections added on "Acceptable Use Policy", "Audit requirements", and "Data handling".
- Updates to removal, renewal, and suspension sections.
--JimBasney 19:56, 29 Sep 2008 (BST)
OSG Perspective
I doubt OSG will adopt this policy. Its mandates are too specific to internal VO management processes, rather than stating more general requirements on the VOs that the VOs can implement as desired. OSG requires VOs to be able to respond to incidents by suspending a user's membership, but OSG does not mandate how the VO contacts the user in that process, but rather considers that an internal matter for the VO. OSG does not require the ability to contact VO members directly; contact is always through the VO manager, operations contact, and security contact.
--JimBasney 19:56, 29 Sep 2008 (BST)
Oct 9 2008 JSPG Meeting Notes
We should add text about Robots (unattended processes with certificates acting on behalf of VOs).
We agree not to require VOs to document their procedures. That's too heavy-weight.
- Could we ask for a sentence about how they verify membership?
We should require users to abide by the VO Acceptable Use Policy (see VO Registration Policy. The VO should verify that the user's work meets the goals of the VO.
- Does the text in Membership Registration cover this? It's not clear.
We need to turn this into a minimum requirements document. It should not "define the procedures".
We did some re-working of the Introduction and Scope and Audience text. Make it clear that these requirements are on the practices ("administrative procedures") of the VO Managers.
OSG is not currently using the template at http://osg-docdb.opensciencegrid.org/cgi-bin/ShowDocument?docid=753. It was deemed too heavy-weight a requirement for VOs to fill out.
--JimBasney 9 Oct 2008
Compare with previous Virtual Organisation Security Policy
"LCG/EGEE Virtual Organisation Security Policy" (version 1.7, dated 31 October 2005) may be found at https://edms.cern.ch/document/573348/6. Section 5.1 of this document was dropped with the update to VO Registration Policy and is now addressed in this policy.
Currently, this policy adds additional requirements above and beyond the previous VO Security Policy requirements.
--JimBasney 16:31, 9 Oct 2008 (BST)
Maria (9 Oct 2008)
Original text taken from the doc. is in italics.
1. Please number (sub)sections.
2. Section: Membership Management Procedures Confusing title. Looks like the doc. title so the Policy/Procedures mixup will arise.
3. "The VO must design and implement procedures to manage ..."
"The VO must describe its implementation of the required procedures in a document ..."
Frightening. Write "The VO must describe the tools/checks used to verify user data at registration time and periodically review users' affiliation with the VO".
4. Section: Appointment of the VO manager The VO must document how it appoints and replaces its VO manager and deputies. Frightening. Usually deputies are backup people. Maybe write "non responsiveness of manager or deputy may lead to VO suspension from the Grid".
5. Section: Membership Registration ... is to collect the user’s Registration Data. Accurate contact and identity information must be maintained for all VO members.
Say what is 'identity information' beyond Registration Data.
Duplication of Personal user data ...
If you mean 'Replication' please use this term.
Robust documented verification procedures must be used ...
Frightening. Use something like 'VO Managers must check the validity of the user Registration data and maintain proof of the user's eligibility for special authorisation (Groups/Roles).
... and those with the authority to exercise control over the rights of the user to use Grid resources.
These can be also site admins. The user has to know that. So we have to ensure that this 'document of procedures' that we now call 'checklist' to make it appear less intimidating is on the VO ID card on the CIC portal and read by the user, or, better, in the VO AUP.
6. Section: Membership Renewal ... Confirmation that continued membership of VO is still allowed,
Can the user claim that or should it be the VO Mgr?
7. Section: Membership Removal
All of the "End of..." dates in this subsection exist in vomrs but not in voms-admin. Please mention this in OSCT or other meeting you go.
8. Section: Membership Suspension
... with or without the user’s consent, in breach of relevant Grid security policies.
What if resource abuse but no security breach? We often have this.
What if the user disputes and wishes to escalate his/her complaint for the suspension?
9. Section: Audit requirements
The VO must record and maintain an audit log of all VO membership transactions.
Say '2 years' straight away. 'maintain' appears 3 times in this doc. but the duration only once on the last page. Problem! VO Managers often have no account on the servers where audit data and logs reside, nor do they know for how long they are kept.
10. Appendix A: Template of VO Membership Management Procedures document Remove appendix.
Oct 10 2008 JSPG Meeting Notes
We discussed Maria's comments above.
Is it a requirement for the VO to provide direct contact to the user from the Grid security team (i.e., phone number, email address)? The OSG Security Officer always works through the VO Security Contact.
Should require every VO to collect and verify phone numbers for all users?
- Jim doesn't think OSG does this.
- EGEE VOs aren't all verifying phone numbers.
Can we state the requirement as the ability to respond to incidents rather than the specific information that must be collected?
How do we move forward regarding what membership data must be collected?
- Should we poll the sites?
--JimBasney 10 Oct 2008
Mods by Dave Kelsey - Version 3.3 - 21 Jan 2009
Modified the document to make sure that all the points discussed in the last JSPG meeting and made by Maria Dimou were addressed.
The issues remaining to be discussed include:
- Do we mandate the collection of user Registration Data or just force the VO to assist in incident response? (An OSG view). This would be a major change!
- Do we need the last section on VO Manager responsibilities?
- The "end-of" dates in membership removal are not available today in VOMS-Admin. How do we cope here?
- Membership Registration - authority to exercise control includes sys admins. CIC portal and VO ID card should state this?
--David kelsey 14:35, 21 Jan 2009 (GMT)
Jan 22 2009 JSPG Meeting Notes
Should the VO Manager (and delegates) be required to sign the AUP and/or be members of the VO?
- No, they only need to sign the AUP if they join the VO and submit jobs.
Should we address the actions of system administrators?
- No, we can expect system administrators to act appropriately and not make inappropriate changes to VO membership.
Should the user have the ability to remove themselves from the VO?
- Dave added a bullet on this saying the user should be able to.
Do we mandate the collection of user Registration Data or just require the VO to assist in incident response? (OSG perspective.)
- In the past, WLCG sites required access to this information.
- We don't require that sites have access to this information anymore.
What are the goals of this policy?
- Want the ability to legally identify a bad user to law enforcement.
- Want the ability to communicate directly with users.
How does this apply to portal interfaces?
- TeraGrid gateways aren't required to collect all this information.
VOs were surveyed about the ability to configure the collection of different user information.
- OSG VOs wanted the ability to collect additional information.
--JimBasney 22 Jan 2009
Feedback received, for discussion at May 2009 JSPG meeting
Rolf Rumler (IN2P3): The policies should also cover de-registration of a VO. How is this done? What needs to be kept? etc etc.
[JSPG response: The common case is that the VO disappeared. We can have a policy about what the VO should do in this case, but it's unlikely it will happen. We addressed the Grid responsibilities here in the VO Registration Security Policy.]
Pete Gronbech (Oxford): Much of the requirements here I would hope are (or could be) provided by the VOMS server used to manage the VO, eg the gridpp one at Manchester. I think a lot of the functionality is missing or not visible at the moment though. There is an 'Check audit data' option but this is greyed out, maybe this is intended for this sort of thing?
- Dates when people joined are not visible.
- End dates do not seem to be implemented.
- Nowhere to record which version of the AUP was applicable when joining the VO
Typo in section 3 "Institute Representative" seems to have lost the last i
[JSPG response: We are indeed very much aware of the lacking functionality in VOMS Admin. There are plans to address all of these, but so far the development is taking much longer than originally planned. JSPG does want the VO tools to be capable of meeting the policy requirements, which we do believe are necessary. We couldn't find the reported typo in section 3.]
Jeremy Coles (Cambridge): Is there a JSPG document that explains our VOMS responsibilities when we want to deactivate a VO?
[JSPG response: VO registration data responsibilities are covered in the VO Registration Security Policy. If the VOMS server is run by a Grid or by a Site, the VOMS and database responsibilities here will be addressed by IGTF in their future document on minimum requirements and best practices for running a VOMS server.]
David Grellscheid (Durham/VO Pheno):
Some of the points in the Membership Management policy are difficult for Pheno to implement without
support from the 'VOMS Admin' software. These are
- 4.4 required Membership renewal every 12 months
- 4.5 record of registration date / end date and the AUP version number
- 4.7 Audit requirements
With our limited manpower, it will be hard to maintain this information externally to the VOMS software, which seems the natural place to store it. Before the policy becomes a mandated requirement, I would like to have support available in the software.
What are the transitional arrangements once the policies come into force? One example is that I will not be able to recreate 2 years' worth of transaction information for our existing users retrospectively, or that the 'pheno' name is not an RFC-compliant string.
[JSPG response: See the above answer on the required changes to VOMS Admin. Transitional arrangements will need to be defined by the various Grids, but clearly it will be difficult to require retrospective changes. We note that the old and currently adopted policy also required VO managers to keep audit logs for 2 years!]
Nick West (Oxford/VO MINOS): I would repeat the plea I made when I when I was migrating our operation to the GRID. There needs to be recognition of situation of a small VO with little available effort. What is required is a ready source of practical advice to ensure their managers comply with the revised regulations.
[JSPG response: Agreed that Grids need to help small VOs as much as possible. We have changed the policy to allow Grids or Sites to offer VO Manager services.]
Now the comments and questions in detail.
Although I can understand the rationale for the change, particular for large VOs, it is going to be additional work. In our case (MINOS), where we will effectively have two heavyweight users and possibly one or two more lightweight ones it looks like overkill.
[JSPG response: If a VO really only has a handful of members, it should be possible to meet all the registration and audit requirements with a pen and a notebook.]
In places I found it hard/impossible to know whether the procedures and systems being referred
to were the responsibility of the VO manager or the VOMS manager. For example the VO database.
What is it, where does the server run and who maintains the contents?
[JSPG response: This policy is aimed very much at the VO manager, as defined in section 3. This is not the same person as the admin of the VOMS server. The VO Registration Security Policy requires the VO to state who is running the VOMS server for them. For a small VO it is very likely that this will be a service run by a Grid or a Site for the VO. The VO Database is the online database, e.g. VOMS, containing the authorisation information.]
Further, we told we must capture and maintain
- Contact details
- Membership details
- explicit acceptance of AUP and version number accepted
- "User Registration Date" and "User Participation-End Date"
Should or could be made part of registration with the VO and held by the VOMS?
[JSPG response: Agreed. See the earlier comments about changes to VOMS Admin.]
Again, the VO Membership Management system(s) that "must record and maintain an audit log, for at least two years, of all VO membership transactions."
Is that a VO or VOMS responsibility?
[JSPG response: The VO is required to ensure that either they or the VOMS service provider keeps the required logs.]
Some specific questions:-
1) Why is it necessary to require "User Participation-End Date" be one year when VO membership has to be renewed annually? Who is meant to provide "a mechanism prompting the user to re-register, before the "User Participation-End Date" is reached"?
[JSPG response: we have simplified the text regarding membership renewal and now participation end date is no longer mentioned.]
2) Privacy policy related to users' Registration Data - why would we want to collect more than the absolute minimum and if we don't can we ignore this?
[JSPG response: All VOs are subject to laws on data privacy whether they like it or not. This is an issue which should be discussed with the body providing VOMS services for you. The policy "recommends" you to consider the privacy issues.]
3) We are told "The VO Manager MUST describe (on the VO ID card) the tools/checks used to verify user data at registration time and periodically review users' affiliation with the VO."
what tools and what frequency?
[JSPG response: We have simplified the policy wording here. For small VOs it can be a few very simple words to describe how you verify data at registration and renewal times.]
4) We are told "VO Managers must check the validity of the user Registration Data and maintain proof of the user's eligibility for special authorisation (Groups/Roles).
what constitutes proof?
[JSPG response: we have replaced the words about proof with "must check". It is up to the VO how they do this.]
Ursula Epting (Karlsruhe):
4.5 Membership Removal, second bullet: "User Registration Date" -> "Data"
[JSPG response: wording of this section has been simplified. The typo went away!]
4.8 Data privacy: I'm not sure about this, but possibly users should also be granted the right to access their "own" data (as described in Grid Policy an the Handling User-Level Job Accountig Data (11)) and have it changed if not accurate
[JSPG response: Agreed. A clause about user access has been added to section 4.8.]
Jeff Templon (NIKHEF): There are many small VOs or don't have a VO Manager. The infrastructure running their VOMS server does everything for them.
[JSPG response: Agreed. The document now allows for VO Managers to be external to the VO.]
Ruth Pordes (OSG) GDB 11 March: No OSG policy currently planned. WLCG and many other VOs on OSG use VOMRS which we understand implies compliance. OSG will have procedures rather than required policy for "traceability of the user such that VO management can find out the user's membership info and link it back to actions on the grid." and procedures that enable management of the users renewal, banning etc. OSG will ask for a variance here as needed.
--David kelsey 13:17, 11 May 2009 (BST)
May 14 2009 JSPG Meeting Notes
For audit records, what happens when VO leaves the Grid?
- Policy specifies records are held for 2 years because renewals are performed annually.
- The common case is "the VO disappeared". We can have a policy about what the VO should do in this case, but it's unlikely it will happen.
- Simply make no statement about it?
Are we still happy with keeping records for 2 years?
- If membership renewal process reconfirms all data, then we don't need records past the most recent renewal.
We acknowledge this policy is not immediately implementable.
- We encourage implementation of the necessary features in VOMS Admin, etc.
- Would also be helpful to have best practices / cookbook documents.
Responsibilities of VO Manager versus VOMS Administrator.
- Definition of VO Manager in Section 3 is still not clear enough?
- Nikhef (for example) provides a VO Manager service to PIs. Perhaps DavidG could describe it here?
There's confusion over "User Participation-End Date".
- This seems to be the date at which renewal must occur.
- We removed the sentence containing this phrase, because it's an implementation detail.
Removed the sentence requiring a "mechanism prompting the VO Manager to remove a user on request" as that's an implementation detail.
In the data privacy section, we added a statement about what happens when the VO dissolves.
We agree that this policy is ready for final call.
--Jim Basney 14 May 2009
Changes Between versions 3.4 and 3.6
Changes included:
- All MUST and SHOULD replaced with lower case.
- Allow for a VO Manager to be external to a VO and offered as a service.
- Remove the requirement (must) for a data privacy policy in section 4 introduction.
- Replace words about recording on the VO ID card (EGEE-specific) with a requirement to "publish".
- Maintaining "proof" of user eligibility for groups/roles reworded as "check".
- Section on membership removal simplified.
- Renewal should happen after major change to Grid AUP.
- Some additional points for the data privacy policy recommendation.
--David kelsey 17:56, 18 May 2009 (BST)
Feedback received and JSPG responses on the "final call" version (V3.6, 18 May 2009)
Rolf Rumler (IN2P3):
- At the end of section 2 of the VO Registration Security Policy it is stated that "Personal registration information must not be retained for more than 12 months". However, in this document, section 4.7, it is said that the VO Membership Management system must keep an audit log for at least two years. As the audit data include personal registration information, this looks as a contradiction to me.
[JSPG response: On the question of retention of personal registration information, this includes names, institute names, e-mail addresses and phone numbers of the users. This is personal data and many countries tell us that keeping this for longer than a year is a problem. The VO Membership Management policy wording has been changed to be the same as in the VO Registration Security Policy. Personal registration data to be kept no longer than one year.]
- It would be fine to have an explicit statement that Grid Operations may have access to a user's personal data, especially the e-mail address, for operational purposes. This is not vital, as Operations may always contact the VO manager, however it speeds up the handling of operational problems considerably.
[JSPG response: Agreed that this would indeed be very useful. Change made to the text about third party access to the membership data in the Data Privacy section.]
--David kelsey 17:56, 18 Jun 2009 (BST)
