[OGSA-AUTHZ] Next Telecon

[Tom Scavo]

On 10/31/06, David Chadwick <d.w.chadwick at kent.ac.uk> wrote:
>
> I believe that the
> "Functional Components of Grid Service Provider Authorisation Service
> Middleware" document is now complete.

Sorry I haven't provided feedback previously since I'm just now coming
to grips with this document (which uses some terminology foreign to
me).  As far as I can tell, there really are only two models,
represented by Figures 1 and 2.  Figures 3 and 4 don't really add
anything new to the model.

I think the PEP needs to (optionally) provide the following additional
data to the context handler (who in turn passes it on to the CVS):

- the unique identifier (entityID) of the Identity Provider that exposes the AA
- the SAML Subject to use as a query subject

These quantities might be bound to the certificate used to
authenticate to the PEP, in the SIA extension and Subject Alt Name
extension, respectively.  See the following discussion thread for more
information along these lines:

http://www.globus.org/mail_archive/gridshib-dev/2006/10/msg00004.html

> If credentials can be packaged as attributes, then only two protocols
> need to be standardised, namely 1/3 and 2.

I don't understand.  Can you explain this a bit more?

> In XACML, an attribute is currently defined as an attribute ID, a data
> type and a value. The contents of all 3 are transparent to the protocol
> and are carried as XML strings. So essentially they can contain
> anything. When we package a credential as an attribute, we simply define
> a new attribute ID and data type to represent the credential and the
> value is then the string encoding of the credential.

Does the "SAML 2.0 profile of XACML v2.0" apply?

> 1. An Attribute, e.g.
> AT ID=role DT=string AV=student, sent as usual with no modifications
> <Attribute AttributeId="urn:oasis:names:tc:xacml:2.0:subject:role"
>              DataType="http://www.w3.org/2001/XMLSchema#string">
>    <AttributeValue>student</AttributeValue>
>   </Attribute>
>
> 2. An X.509 attribute certificate credential in which
> AT ID=X.509AC DT=BER AV=<some BER>,
> AT is sent as <Attribute AttributeId="://www.ieft.org/rfc/rfc2256.txt#
> attributeCertificateAttribute"
> the value is base64 encoded into a string, and the DT is either string
> or Base64 string (if this exists)
>
> 3. A SAML Attribute Assertion credential
> AT ID=SAML Attribute Assertion DT=XML AV=<SAML AA XML>, we need to
> define an attribute ID for a SAML Attribute Assertion (unless this
> already exists), the DT is string, and then we send the value enclosed
> in speech marks " "

Are you suggesting that SAML attributes be repackaged as XACML
attributes?  (The "SAML 2.0 profile of XACML v2.0" profiles exactly
this, btw.)  At what step of the flow will this mapping occur?

> 4. An X.509 Public Key certificate with Subject Directory Attributes
> credential. Send in the same way as an X.509 AC, except that ID is
> userCertificate.

Thanks,
Tom