Hi All, Sounds like you had a good discussion. Sorry I missed it. I've been fighting a virus all week and a 5 AM telecom was a bit too challenging. A few comments in-line. Blair Dillaway
-----Original Message----- From: ogsa-authn-bof-bounces@ogf.org [mailto:ogsa-authn-bof- bounces@ogf.org] On Behalf Of Alan Sill Sent: Thursday, March 08, 2007 6:03 AM To: Hiro Kishimoto Cc: OGSA AUTHZ WG; ogsa-wg; OGSA Authentication WG BoF Subject: [ogsa-authn-bof] Minutes of OGSA-WG + OGSA-AuthZ Joint telephone call 8 Mar 2007
Minutes of OGSA-WG + OGSA-AuthZ Joint telephone call 8 Mar 2007
Attending: Hiro Kishimoto Dave Snelling Marg Murray Dave Chadwick Chris Kantarjiev David Groep Dwayne Merrill Mark Morgan Andrew Grimshaw
Proposed Agenda from David Snelling:
1) Clarify the need for AuthZ standards in a Grid. Do we need AuthZ standards within in a single enterprise or only with distributed grids.
2) Review the scope of the current AuthZ WG. Are they doing frameworks only, or are they defining roles and their semantics? What is the scope of these and how is extensibility managed?
3) Are the AuthZ requirements the same for both Enterprise and eScience?
4) Is there something in needed in AuthZ that is either a) not being addressed by the AuthZ-WG or b) needed is a short time frame as a stop gap?
Dave S. reviewed the above agenda. Agenda bashing ensued. David C. felt Item 3 should be addressed first. A wiki for requirements has been created but has not been heavily trafficked yet.
[blaird] My experience is that there are some significant differences in practice, though that doesn't necessarily mean one needs different mechanisms. These types of requirements can be difficult to nail down. Often they have to be 'teased' out of more general business or regulatory requirements and Enterprises may be reluctant to make these public.
David S. asked whether AuthZ is best considered local or non-local. Alan responded that in his view, authorization always takes place locally, but often must be informed by factors that come from outside of the local boundary. David C. pointed out that this discussion, while true, is at a different level than the current activities of the OGSA-AuthZ group, which focuses on protocols for transmission of authorization-related information, rather than particular specific schema or attributes. (This was an important principle in getting AuthZ activities going forward in a useful way toward standardization of the _syntax_ of attributes.) He held out the example of LDAP, which went through a similar evolution.
Marg Murray asked about the split between authN and authZ as it relates to virtual organizations. David C. reviewed the agreement that has been underlying the OGSA AuthZ work to date that assumes that VOs will be authoritative for some but not all attributes, just as institutions are authoritative for some but not all attributes, so what is needed and what the group has been working on has been methods to encode, transmit and understand attributes.
Andrew joined and gave the opinion that advertisement, discovery and communication of information is preferable to hard specification of attributes, which is consistent with the above.
[blaird] I see two important aspects to this. First, authorities need to be able to communicate what they are authoritative for (attributes, types of principal identities, ...) so that resource admins can know what they can rely upon in developing authZ policies. Second, resources need to be able to communicate what authenticated information they require (token types, which authorities, ...). WS-SecureConversation (http://www.oasis-open.org/committees/download.php/15979/oasis-wssx-ws-securi...) could potentially be profiled as a way to do the latter. I'm not aware of an existing std that addresses the former.
Moving on to the roadmap, David C. referred to the OGF-16 SAML-based profile, which was felt to be deficient compared to the community assessment of needs. Two profiles are being worked on by the group at present, one based on XACML and one based on WS-Trust, and an architecture document. These are current in the OGSA-AuthZ gridforge pages. There is also a document describing these deficiencies from the previous approach, which include: inability to describe obligations (solved in the XACML case), need to describe parameters of actions, etc. Note the XACML-over-SAML approach used here has NOT been deprecated by OASIS, as reported earlier e.g. at OGF-20, according to David C. as per an e-mail that he will forward to the group.
David S. proposed that the above discussion covers agenda item 2) for today, if supplemented by e-mails documenting the above points by those who made them. There does seem to be work for a framework for authorization that goes beyond the WS standards available to the community. Andrew pointed out a statement by Nate Klingenstein at last week's meeting regarding work by the Liberty Alliance that specifies extensions to WS-Security -- we need to track down a reference on this. Dwayne clarified that this specifies usage of the key within the metadata in an EPR. David C. said that we cannot escape the fact that every credential can in principle have a policy associated with or attached to it. It may be a usage field or a policy context. Thus the encoding format for that policy should be standardized. In X.509 this is done by a complex arrangement of OIDs. The recipient of a credential can always choose to ignore such policy statements, of course.
David S. asked whether existing work covers the topic of advertisement of authorization requirements on the part of a given resource to describe what it needs to make an authZ decision. David C. said that there is a feature in XACML that could support this, but that this work has not been completely fleshed out yet by documents produced by OGSA-AuthZ. The PEP is the application-dependent piece; other application dependence is factored out. Andrew asks how can one determine what needs to be sent along in the SOAP? David C. (and Alan agreed) replied that some of these requirements may be published out of band, for efficiency, privacy or other reasons that do not necessarily have to interfere with such discovery.
[blaird] Again, WS-SecurityPolicy may be a useful starting point, though it would need to be profiled for grid needs.
Reviewing the agenda, David S. stated that item 1) is also answered now as well. Item 3) may require more extended discussion. A requirements roll-up activity is taking place throughout OGF now and he felt that this should be brought up at the next such roll-up meeting.
In terms of item 4), are there any short-term actions or needs that we can identify? David C. felt that interaction with credential issuing services to determine whether a given credential service can respond to a specific request needs to be documented. The field definition needs a look, too. Andrew asked whether there are use cases driving these requirements. The use cases he is looking at are simpler and don't seem to require some of the above. Dave S. pointed him to the wiki and asked for input.
[blaird] I suspect there is work we could be doing around delegation for interop, particularly standard ways of communicating delegation credentials and for advertising what forms of delegation tokens are acceptable to a resource.
Andrew reminded the group of the informational document being worked on as a result of last week's discussion, and that this has been sent out to the OGSA-WG list. Hiro asked for review of this document to be scheduled in the Thursday F2F Security session.
Hiro asked about the next joint call in this series. Candidates are Mar. 29, April 5, 12 and 19. None of April dates would work for David C. so Mar. 29th was selected and agreed to.
Respectfully,
Alan Sill, Ph.D TIGRE Senior Scientist, High Performance Computing Center Adjunct Professor of Physics TTU
==================================================================== : Alan Sill, Texas Tech University Office: Admin 233, MS 4-1167 : : e-mail: Alan.Sill@ttu.edu ph. 806-742-4350 fax 806-742-4358 : ====================================================================
_______________________________________________ ogsa-authn-bof mailing list ogsa-authn-bof@ogf.org http://www.ogf.org/mailman/listinfo/ogsa-authn-bof