[OGSA-AUTHZ] [ogsa-authn-bof] Minutes of OGSA-WG + OGSA-AuthZ Joint telephone call 8 Mar 2007

[Blair Dillaway]

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 at ogf.org [mailto:ogsa-authn-bof-
> bounces at 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-securitypolicy-1.0.pdf) 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 at ttu.edu   ph. 806-742-4350  fax 806-742-4358  :
> ====================================================================
>
>
> _______________________________________________
> ogsa-authn-bof mailing list
> ogsa-authn-bof at ogf.org
> http://www.ogf.org/mailman/listinfo/ogsa-authn-bof