[ogsa-wg] draft minutes for OGSA-Authz call-out proposal review (Aug 11)

Hiro Kishimoto hiro.kishimoto at jp.fujitsu.com
Mon Aug 28 07:43:10 CDT 2006


OGSA Teleconference - 11 August 2006
====================================

* This is first half of Aug. 11 call *

* Participants

   Andrew Grimshaw (UVa)
   Jay Unger (IBM)
   Frank Seibenlist (ANL)
   Steven Newhouse (OMII)
   Takuya Mori (NEC)
   Marvin Theimer (Microsoft)
   Jem Treadwell (HP)
   Duane Merrill (UVa)
   David Chadwick (U of Kent)
   Andreas Savva (Fujitsu)
   Donal Fellows (Uom)

   Minutes: Takuya Mori

* OGSA authorization call-out proposal review (Frank, 20 min)

Reference:
"Functional Components of Grid Service Provider Authorisation Service
Middleware"
https://forge.gridforum.org/sf/go/doc13724?nav=1

David presented a draft document, "Functional Components of Grid Service
Provider Authorisation Service Middleware", which was sent to the
OGSA-AuthZ and OGSA-WG list on Aug 9.
(The document was based on discussions between Von, Frank and David.)

David introduced functional components, Policy Enforcement Point (PEP),
Credential Validation Service (CVS) and PDP (Policy Decision Point) and
showed four types of interactions between the components (See Fig.1 to
Fig.4 in the document).  David proposed to define two protocols, one
for CVS and the other for PDP.

The followings are the points of his proposal.
- CVS is used to validate credentials and to issue valid attributes of
   Access Requestors.
- CVS is passed authenticated name and credentials.
- CVS determines if the credential is trust worthy and returns valid
   attributes.
- An administrator manages two types of rules, auhtz decision rules and
   rules to resolve trust relationships
- CVS makes use of XACML policy query interface, but it is not
   necessarily be an XACML policy engine behind the interface.
- CVS is needed to separate authentication and authorization.

Various questions and answers arouse during the presentation and some
major points made clear in the discussion were:
   - The two protocols are intended to support all the configuration
     shown in the figures
   - Revisions of the two "OGSI" profiles are also in the scope of
     current activities of the OGSA-AuthZ-WG.
   - Defining attributes values (terms and semantics) is not in the
     scope of current activities of the OGSA-AuthZ-WG, but in its
     future scope.
The discussion were suspended until Aug 28 due to the running out
of the meeting time.

The followings are some interactions during the discussion.
* The scope of the work (1)
Q: Does the two protocols cover all the configurations shown in
    the figures?  The protocols shown in the figures look different.
A: Yes, the both protocols can cover all the configuration.  The
    current OGSA-Authz profiles can handle this kind of interactions.
Q: The current profiles are not "OGSA" profiles.  These are "OGSI"
    profiles.
A: The difference between "OGSI" and "OGSA" is small for OGSA-Authz
    profiles.  Revisions of these two profiles are also on the table.

* How to define service I/F of applications
Q: As an application desginer, do I need to choose appropriate one?
   * long interactions were taken place which Takuya couldn't perfectly
     follow, but if Takuya understood well, the answer from the authz
     wg is: *
A: Interafces of applications will not be affected.  It is the
    middleware which speaks the protocols.  Authorization is taken
    place behind the infrastructure.

* The scope of the work (2)
Q: The architecture for authorization has not clearly been defined.
    What the OGSA-AuthZ-WG are going to define?  Do we need to define
    all the comopnents?  Various terms and semantics also needs to
    be defined for attributes and policies.  These also should be
    standardized.
A: The OGSA-AuthZ-WG did the similar things in the past,
    the credential formats and terms over the SAML Attribute Assertion
    and the X.509 Attribute Certs.
Q: It covers a different interop level - only attribute name or type
    level - not the values.
A: The OGSA-AuthZ-WG focuses only on the interface level.
    David doesn't have a need to define values. (at this moment?)
    The WG needs to define them later in the future.

-- 
Hiro Kishimoto





More information about the ogsa-wg mailing list