some thoughts on attribute mapping of an XACML request context
Hi, The following is some thought on attribute mapping of an XACML request context. I hope it will be a good input for today's discussion. Thanks, Takuya ---- Feb. 13, 2007 Takuya Mori 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? - ... [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. 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. 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. 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. 2. Resource Attributes [XACMLProfile] document specifies that the resource attribute of an XACML request context should be the value of wsa:To header of an incoming request message, which is an endpoint reference of a service interface to which the request is sent. [OGSA-WSRFBasicProfile] docuemnt defines a set of profiles to embed reference properties into an endpoint reference which enables to specify a WS-Resource, a stateful resource behind a service interface of a Web Service. Therefore, the profile specified in the current [XACMLProfile] document is sufficient for specifying a WS-Resource in an XACML request context. There may be a case where some service providers need to make an authorization decision on information appeared in a message body. For example, a user who is submitting a job to an job execution service can request some amount of computing resources in a JSDL document and a service owner of the job execution service would like to make an authorization decision based on the amount of comuting resources requested in the JSDL document. Because information which appeared in a message body is consumed by a service, the authorization decision discussed here can be said as application level authorization. In my opinion, a support for such authorization decision on middleware level is helpful for application developers because not all such the developers can design authorization mechanisms for their application. In case of NAREGI's AuthZ service, in order to address the requirement for application level authorization, Resource Attribute Filtering Mechanism, a flexible and configurable method to specify a mapping between resource descriptions in a request message and resource attributes of an XACML request context is introduced. RAFM is configured by a Resource Mapping Description which defines such mapping rule and only a owner of a service can configure it. The following is an example of a Resource Mapping Description. List.1: An example of a Resource Mapping Description ---- 01: <resource_maps> 02: <namespaces> 03: <namespace prefix="ns1" value="http://schemas.ggf.org/jsdl/2005/06/jsdl"/> 04: </namespaces> 05: <map> 06: <input_element>//ns1:Resources/ns1:TotalResourceCount/ns1:Exact </input_element> 07: <xacml_resource_attribute_id>naregi:TotalResourceCount </xacml_resource_attribute_id> 08: </map> 09: </resource_maps> ---- 02..04: a <namespaces> element defines namespace declarations that are used in an XPath expression in a <input_element> element. 06: a value of an <input_element> is an XPath expression for specifying a resource description in a message body of a request message. 07: a value of an <xacml_resource_attribute_id> element is an resource attribute id that will be used in an XACML request context to specify the resource specified by the XPath expression in the line 06. The description above will make the RAFM to convert the fragment of an JSDL document shown in List.2 to the XACML resource attribute described in List.3. List.2: a fragment of an JSDL document ---- 01: <Resources> 02: <TotalCPUCount> 03: <Exact>1</Exact> 04: </TotalCPUCount> 05: </Resources> ---- List.3: an example of a resource attribute of an XACML request context ---- 01: <Resource> 02: <Attribute AttributeId="naregi:TotalResourceCount"> 03: <AttributeValue>1</AttributeValue> 04: </Attribute> 05: </Resource> ---- There may be an issue that a malcious user may specify a spoofed value in a message body which can cause the authorization component to make a false decision on the service access. In my opinion, in order to provide some service to a user, a service owner need to trust a content of the reqest message in some extent, because the content will be used for some computation behind the service. Therefore, the information in the request message can also be used for authorization decision with the same level of the trust that the computation relys on at the service owner's choice. A. References [XACMLProfile] Use of XACML Request Context to access a PDP, David W. Chadwick et al. [AuthzFunc] Functional Components of Grid Service Provider Authorisation Service Middleware, David W. Chadwick et al.
Hi Takuya Here is my input for todays telecon Takuya Mori wrote:
Hi,
The following is some thought on attribute mapping of an XACML request context. I hope it will be a good input for today's discussion.
Thanks, Takuya
---- Feb. 13, 2007 Takuya Mori
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.
2. Resource Attributes [XACMLProfile] document specifies that the resource attribute of an XACML request context should be the value of wsa:To header of an incoming request message, which is an endpoint reference of a service interface to which the request is sent. [OGSA-WSRFBasicProfile] docuemnt defines a set of profiles to embed reference properties into an endpoint reference which enables to specify a WS-Resource, a stateful resource behind a service interface of a Web Service. Therefore, the profile specified in the current [XACMLProfile] document is sufficient for specifying a WS-Resource in an XACML request context.
There may be a case where some service providers need to make an authorization decision on information appeared in a message body. For example, a user who is submitting a job to an job execution service can request some amount of computing resources in a JSDL document and a service owner of the job execution service would like to make an authorization decision based on the amount of comuting resources requested in the JSDL document. Because information which appeared in a message body is consumed by a service, the authorization decision discussed here can be said as application level authorization. In my opinion, a support for such authorization decision on middleware level is helpful for application developers because not all such the developers can design authorization mechanisms for their application.
Agreed. This would be up to the application PEP to pick up the correct information for the PDP
In case of NAREGI's AuthZ service, in order to address the requirement for application level authorization, Resource Attribute Filtering Mechanism, a flexible and configurable method to specify a mapping between resource descriptions in a request message and resource attributes of an XACML request context is introduced. RAFM is configured by a Resource Mapping Description which defines such mapping rule and only a owner of a service can configure it.
The following is an example of a Resource Mapping Description.
List.1: An example of a Resource Mapping Description ---- 01: <resource_maps> 02: <namespaces> 03: <namespace prefix="ns1" value="http://schemas.ggf.org/jsdl/2005/06/jsdl"/> 04: </namespaces> 05: <map> 06: <input_element>//ns1:Resources/ns1:TotalResourceCount/ns1:Exact
I think you mean TotalCPUCount
</input_element> 07: <xacml_resource_attribute_id>naregi:TotalResourceCount </xacml_resource_attribute_id> 08: </map> 09: </resource_maps> ---- 02..04: a <namespaces> element defines namespace declarations that are used in an XPath expression in a <input_element> element. 06: a value of an <input_element> is an XPath expression for specifying a resource description in a message body of a request message. 07: a value of an <xacml_resource_attribute_id> element is an resource attribute id that will be used in an XACML request context to specify the resource specified by the XPath expression in the line 06.
The description above will make the RAFM to convert the fragment of an JSDL document shown in List.2 to the XACML resource attribute described in List.3.
List.2: a fragment of an JSDL document ---- 01: <Resources> 02: <TotalCPUCount> 03: <Exact>1</Exact> 04: </TotalCPUCount> 05: </Resources> ---- List.3: an example of a resource attribute of an XACML request context ---- 01: <Resource> 02: <Attribute AttributeId="naregi:TotalResourceCount"> 03: <AttributeValue>1</AttributeValue> 04: </Attribute> 05: </Resource> ----
There may be an issue that a malcious user may specify a spoofed value in a message body which can cause the authorization component to make a false decision on the service access. In my opinion, in order to provide some service to a user, a service owner need to trust a content of the reqest message in some extent, because the content will be used for some computation behind the service. Therefore, the information in the request message can also be used for authorization decision with the same level of the trust that the computation relys on at the service owner's choice.
I agree David
A. References [XACMLProfile] Use of XACML Request Context to access a PDP, David W. Chadwick et al. [AuthzFunc] Functional Components of Grid Service Provider Authorisation Service Middleware, David W. Chadwick et al.
------------------------------------------------------------------------
-- ogsa-authz-wg mailing list ogsa-authz-wg@ogf.org http://www.ogf.org/mailman/listinfo/ogsa-authz-wg
-- ***************************************************************** David W. Chadwick, BSc PhD Professor of Information Systems Security The Computing Laboratory, University of Kent, Canterbury, CT2 7NF Skype Name: davidwchadwick Tel: +44 1227 82 3221 Fax +44 1227 762 811 Mobile: +44 77 96 44 7184 Email: D.W.Chadwick@kent.ac.uk Home Page: http://www.cs.kent.ac.uk/people/staff/dwc8/index.html Research Web site: http://www.cs.kent.ac.uk/research/groups/iss/index.html Entrust key validation string: MLJ9-DU5T-HV8J PGP Key ID is 0xBC238DE5 *****************************************************************
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
participants (3)
-
David Chadwick -
Takuya Mori -
Valerio Venturi