[OGSA-AUTHZ] Fwd: Draft notes for OGSA-Authz, GGF15, Wed. Oct. 5, 2005 6-8 pm

[Von Welch]

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 at ttu.edu>
> Date: October 5, 2005 8:11:21 PM CDT
> To: Von Welch <vwelch at NCSA.UIUC.EDU>, Frank Siebenlist  
> <franks at mcs.anl.gov>, David Chadwick <D.W.Chadwick at kent.ac.uk>,  
> Olle Mulmo <mulmo at pdc.kth.se>, Dane Skow <dane at FNAL.GOV>
> Cc: Alan Sill <Alan.Sill at 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 at ttu.edu   ph. 806-742-4350  fax 806-742-4358  :
> ====================================================================
>
>