Many thanks to Alan for these notes. Please send any corrections or clarifications in the next week and then I will post. Von Begin forwarded message:

From: Alan Sill <Alan.Sill@ttu.edu> Date: October 5, 2005 8:11:21 PM CDT To: Von Welch <vwelch@NCSA.UIUC.EDU>, Frank Siebenlist <franks@mcs.anl.gov>, David Chadwick <D.W.Chadwick@kent.ac.uk>, Olle Mulmo <mulmo@pdc.kth.se>, Dane Skow <dane@FNAL.GOV> Cc: Alan Sill <Alan.Sill@ttu.edu> Subject: Draft notes for OGSA-Authz, GGF15, Wed. Oct. 5, 2005 6-8 pm

Please comment and/or go ahed and post -- or point me to a place where you would like me to post these.

Alan

OGSA Authz -- GGF15 - Wed. Oct 5 2005, 6-8 pm

Von Welch reviewed overall goals for this group, and began by focusing on the status of current documents. All of these have been submitted to the editor.

SAML Authorization Service: https://forge.gridforum.org/tracker/?aid=1612 A comment exists on the steering group tracker, but has not yet been sent to the mailing list. The thrust of this comment is on whether this is an appropriate time to undertake this activity. The document does appear but the above comment does not appear on the public list right now, possibly due to this question.

Action item: Security area coordinator will track down status of this document and inform the group. (URL has been sent to Von; he will post this.)

OGSI Authz Requirements https://forge.gridforum.org/tracker/?aid=1613

Similar status.

Attributes document (previously submitted): https://forge.gridforum.org/tracker/index.php?aid=1485

Some comments have been made wondering what it was about. Document may be historical at this point? Document never became as intended, which would have been a full description of the relevant attributes as a starting point for interoperability. Right people from potential users (e.g., OSG and EGEE) may not be involved, so the plan is to re-initiate discussions with these potential users of such a document. Perhaps this one should be publicly withdrawn, as it attempted to be a recommendation, or relabeled explicitly as informational or experimental. After discussion, the decision was to make this document experimental. Mary will do this.

Frank S.: XACML

XACML 2 is out now, and XACML 3 is under development. The latter includes all delegates that may have played a role in the chain. It happens that the XACML working group is meeting in California at the same time as this meeting. The agenda of that meeting includes further resolving the XACML 3 spec. Meanwhile, we can look at XACML 2 and wait until 3 is fully specified, keeping in mind the kind of revisions that are likely to be made. Frank is confident that there will be something useful from this process by or before the next GGF.

Multiple inputs into this process exist. The PDP = Policy Decision Point for XACML consists of a list of attributes and their semantics, close enough to use for PERMIS also. The XACML 3 spec currently includes also some credential validation components also. Some sentiment exists that this functionality should exist in the credential proofing stage, rather than the authorization stage. Mixing credential validation and decision logic may not be a good idea, due to multiple iterations of communication that would have to be done in that case. Adding delegation validation into the PDP into the token validation would perhaps impact performance. Frank responds that there is a difference between attribute delegation and transfer of rights; authorization should be done separately. XACML interface only takes care of first and not second of these. Should we be feeding in requirements for the OGSA-Authz service to the XACML process?

Microsoft's WS-Trust work was mentioned, but it is opaque at this point since they have not released sufficient information on its internals. They were supposed to deliver this to OASIS in September but have not done so to anyone's knowledge yet.

Some requirements and a conceptual model do exist in the form of toolkits that produce and validate credentials presently in the field. Can requirements be written based on these and our current thoughts as to where this is going, in order to feed into the XACML spec process, for example? The previous requirements document from the earlier group was mentioned, chaired by Marcus Lorch; it was felt that although this is dated now and does not mention explicitly either delegation or web services a la GT4, for example, it could be a good starting point. Note that some implementations go beyond earlier specs significantly, for example the "2005- leading-edge" variants of X509 for attribute certificate validation in recent research implementations (e.g. DIS = Delegation Issuing Service) done by David Chadwick's group.

Ollie Mulmo mentioned that the "black box" approach may not be responsive to the needs of a specific service, for example storage.

Von asks, paraphrasing Dane Skow, "where are the rub points that need to be addressed here?" Distinguish PIP = Policy Information Point from PDP. David says this may not be enough: WS-Trust, for example, has 3 separate services that are required: Credential Issuing, Credential Validation, and Credential Translation. David says there is a architecture in the EU Trustcom project that might be informative, and will post this if possible. Distributing it in the context of GGF WG may require a close look at the IP policies, but was felt to be possible.

It was not clear in subsequent discussion as to whether this could lead in short term to the kind of concrete input to the XACML process that is needed right now. An alternative might be to look at explicit existing examples, such as the SRM = Storage Resource Manager and related authenticated access to storage work presented earlier in the week by Abhishek Rana earlier this week, for example.

The question was raised that we have been through this process before, and need to avoid the temptation to descend into fruitless discussion and chaos. One way to avoid this would be a GGF use case repository for examples that are explicitly related to security. For example, Malcolm earlier today talked about a data work flow and was interested in defining the points within the workflow at which he would need security and authorization input. Andre is putting together such a repository. Von will post the URL for this repository to the OGSA-Authz mailing list. We could use the gridforge tracker to keep tabs on how many of these have been read and reviewed from this group. An editor should also be identified for a summary document to contain the results of this reading and review.

Another area that can look at this topic is the overall Security Area within GGF.

Dane points out that many developers and users seem to believe that simply describing a security need immediately leads to a solution being developed and offered. Nonetheless, looking at proposed use cases and described needs does help map the range of work to be done. To what level should we be giving input into other groups to describe what is easy, and what is hard? Again, in the example of storage, whenever you change a management domain, you need a callout to an authorization service. There are performance implications, therefore, regarding architectural decisions about where to put such callouts and where they take effect.

Examples of use of callouts are to tie in to legacy systems, or to bridge between existing systems (for example PERMIS and GT4). There should be symmetry between exiting and entering a domain in terms of authorization functionality. Application developers need to be in dialogue with this process; Bob Cowles points out the value of an iterative approach to standards and release, rather than a "shoot-for-perfect" approach; users will ask for too much at first if asked for a laundry list of their needs.

Conclusions: (a) Led then by an "80/20"-like rule -- what 80% of user requirements can we get with the minimum immediate steps, we should try to turn real-world experience into specifications , and also (b) an effort should be made to give input as to what "that security block" means in various other groups, as guidance as to what is possible right now and in the near future. On the latter point, Ollie, Dane and Von volunteered to try to get this process started. David suggested that application developers and other interested parties be asked for short "security focus use case" statements, preferably prioritized where possible.

Dane suggests that people look at the OGSA architecture and at implementation documentation for various projects in order to sharpen this process. Von and David then brought up a document that has been floating around as to how to bridge various authorization components in a "plug and play" manner that is not quite ready for release, but that could be useful for discussion. The mixing of authentication and authorization by Shibboleth, for example, was mentioned; such mixing may cause more problems than it solves, so defining needs so that they can be separated into the required services in the separate realms.

==================================================================== : 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 : ====================================================================