Here's the URL for the SAML document with the GFSG comments (and now
my response).
Von
Begin forwarded message:
> From: Dane Skow <dane(a)fnal.gov>
> Date: October 5, 2005 5:19:24 PM CDT
> To: vwelch(a)ncsa.uiuc.edu
>
>
>
> Here's the URL for the tracker for the AuthZ Service document.
> https://forge.gridforum.org/tracker/index.php?aid=1612
>
>
>
Here is the (temporary) url to the list of use cases that I mentioned
in the meeting yesterday. The plan is it will eventually be moved
onto the main GGF site.
Von
Begin forwarded message:
> From: Andre Merzky <andre(a)merzky.net>
> Date: October 5, 2005 4:29:31 PM CDT
> To: vwelch(a)ncsa.uiuc.edu
> Subject: use cases...
> Reply-To: Andre Merzky <andre(a)merzky.net>
>
>
> have fun:
> http://fs0.das2.cs.vu.nl:9090/twiki-test/bin/view/UseCases/WebHome
>
> --
> +-----------------------------------------------------------------+
> | Andre Merzky | phon: +31 - 20 - 598 - 7759 |
> | Vrije Universiteit Amsterdam (VU) | fax : +31 - 20 - 598 - 7653 |
> | Dept. of Computer Science | mail: merzky(a)cs.vu.nl |
> | De Boelelaan 1083a | www: http://www.merzky.net |
> | 1081 HV Amsterdam, Netherlands | |
> +-----------------------------------------------------------------+
>
>
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(a)ttu.edu>
> Date: October 5, 2005 8:11:21 PM CDT
> To: Von Welch <vwelch(a)NCSA.UIUC.EDU>, Frank Siebenlist
> <franks(a)mcs.anl.gov>, David Chadwick <D.W.Chadwick(a)kent.ac.uk>,
> Olle Mulmo <mulmo(a)pdc.kth.se>, Dane Skow <dane(a)FNAL.GOV>
> Cc: Alan Sill <Alan.Sill(a)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(a)ttu.edu ph. 806-742-4350 fax 806-742-4358 :
> ====================================================================
>
>
