[OGSA-AUTHZ] some thoughts on attribute mapping of an XACML request context

[Valerio Venturi]

> >      a note on attribute mapping of an XACML request context
> >                                                         
> > 1. Subject Attributes
> > Any attributes asserted in credentials of a subject attached to a
> > request message should be taken into the consideration of the authz
> > decision.  Therefore, such attributes should be embedded into an XACML
> > request context as its subject attributes.
> > 
> > The followings are an example of such credentials:
> > - X.509 Certificates  
> > -- public key certificates
> > -- attribute certificates
> > -- proxy certificates
> > - VOMS Attribute Certificates (actually, it's a kind of X509 attr 
> >   certs)
> > - privilege credeitnals such as PERMIS, CAS, ... credentials
> > - others?  Username/Password Tokens?, Kerberos Tickets?
> 
> I generally agree with you, but note that there are no PERMIS specific
> credentials, they are all pure X.509 ACs.
> 
> 
> > - ...
> > 
> > [AuthzFunc] document defines four types of interactions between
> > authorization functional components.  In case of two PEP Context
> > Handler Models, because the validity of the credentials are validated
> > on the PDP side, the whole credentials of the subject should be passed
> > to the PDP in an XACML request context.  Therefore, it is needed to
> > define a subject attribute format of the XACLM request context which
> > can hold a binary credential within it.
> > 
> > On the other hand, in case of two PEP Context Handler Models, the
> > validity of the credentials are validated on the PEP side and the
> > validated attributes are passed to the PDP in an XACML request
> > context.  Therefore, there is a need to define a rule to map such
> > validated attributes into XACML subject attributes.
> > 
> > As a conclusion, regarding with our [XACMLProfile] document, what we
> > need for our subject attribute profile is:
> > 1) a way to embed a binary credential into a subject attribute of 
> >    an XACML request context.
> 
> Agreed. I suggest that we can give a rule to say
> 
> i) base64 encode the credential, then use the <SubjectAttributeDesignator>
> 
> 
> > 2) a way to map an attribute of a generic credential such as X.509 
> >    public key certificate into a subject attribute of an XACML 
> >    request context.#
> 
> We can use the XACML spec for this. We should encourage people to use
> standard LDAP attribute types wherever possible, since this is supported
>  directly by XACML. The "AttributeId" field is set to the RFC number and
> attribute name e.g.for the user password LDAP attribute defined in
> RFC2256 it would be
> 
> http://www.ietf.org/rfc/rfc2256.txt#userPassword
> 
> For X.509 attributes that are not already defined in LDAP, we can use
> the OID urn format, which I think is
> 
> urn:oid:<dotted number notation for OID>
> 
> 
> > 3) a way to map an attribute of popular credential formats such 
> >    as VOMS attribute certificate, Shibboleth attribute assertions, 
> >    etc... The scope of credential types to support by 
> >    the [XACMLProfile] document should be defined based on the 
> >    requirements by the community.
> 
> We can use the OID format for these where OIDs exist.
> 
> > 
> > In case of NAREGI, X.509 proxy certificates as well as VOMS attribute
> > certificates are used for authentication and authorization.  And
> > NAREGI's AuthZ service is based on "PEP Context Handler + Push" model
> > defined in the [AuthzFunc] document.  The subject attributes used in
> > NAREGI for AuthZ are shown below.
> > 
> > - UserDN:
> >   ID: "urn:oasis:names:tc:xacml:1.0:subject:subject-id"
> >   Value: User's "Globus ID" (in String format)
> > - VOMS VO Name Attribute:
> >   ID: “naregi:vo:voName”
> >   Value: VO Name (in URI format)
> > - VOMS Group Attribute:
> >   ID: “naregi:vo:group”
> >   Value: Group Name (in String format)
> > - VOMS Role Attribute:
> >   ID: “naregi:vo:role”
> >   Value: Role Name (in String format)
> > - VOMS Capability Attribute:
> >   ID: “naregi:vo:capability”
> >   Value: Capability Name (in String format)
> > 
> > The IDs described above are tentative and it is preferable to have
> > standardized IDs for them.
> 
> I agree we need to have standard names for these. This is something the
> group will need to discuss and agree upon.

For what concern those related to VOMS (voName, group, role, capability
above), we are in the process of defining a SAML rendering for VOMS
attributes and this should sort this out as well, given the mapping
rules to XACML attributes defined in SAML profile of XACML.
How long the process will be I cannot say for sure. I hope we'll hand in
something for a discussion before OGF.

Valerio

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3339 bytes
Desc: not available
Url : http://www.ogf.org/pipermail/ogsa-authz-wg/attachments/20070418/119cf497/attachment.bin