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

Tue Feb 13 09:02:11 CST 2007

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.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pkcs7-signature
Size: 3435 bytes
Desc: not available
Url : http://www.ogf.org/pipermail/ogsa-authz-wg/attachments/20070214/9c8e2c88/attachment.bin 