OASIS eXtensible Access Control Markup Language (XACML) TC

Re: [sunxacml-discuss] XACML: Access Control for Web Services. Forwarded message from Anne Anderson.

  • 1.  Re: [sunxacml-discuss] XACML: Access Control for Web Services. Forwarded message from Anne Anderson.

    Posted 10-07-2003 15:32
     MHonArc v2.5.0b2 -->
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    

    xacml message

    [Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


    Subject: Re: [sunxacml-discuss] XACML: Access Control for Web Services. Forwarded message from Anne Anderson.


    ------- start of forwarded message -------
    From: Anne Anderson <Anne.Anderson@Sun.com>
    To: Chiusana Joseph <chiusana_joseph@bah.com>
    CC: Anne.Anderson@Sun.com, sunxacml <sunxacml-discuss@lists.sourceforge.net>
    Subject: Re: [sunxacml-discuss] XACML: Access Control for Web Services
    Date: Tue, 7 Oct 2003 11:32:30 -0400
    
    Joseph,
    
    Let me try answering your question.
    
    There are several aspects of using XACML for access control with web
    services:
      1) how is the access control policy expressed?
      2) how are attributes conveyed via standard web services
         protocols such as SAML used in XACML access control
         policies?
      3) how is the web service bound to the XACML policy?
      4) how is the XACML access control policy bound to the web
         service?
    
    1. HOW IS THE POLICY EXPRESSED
    
    This is done through standard XACML rules, which state conditions
    under which access is allowed.  The XACML 1.1 specification is
    available at:
    http://www.oasis-open.org/committees/xacml/repository/cs-xacml-specification-1.1.pdf
    
    The access control policy for an on-line book club web service
    may be that only members of the on-line book club can order items
    from the club's web site.
    
    This would be expressed in XACML as follows:
    
          <Rule Effect="Permit">
            <Condition FunctionId="and">
              <Apply FunctionId="equal">
                <AttributeValue>member</AttributeValue>
                <SubjectAttributeDesignator AttributeId="membership-status"/>
              </Apply>
              <Apply FunctionId="equal">
                <AttributeValue>order</AttributeValue>
                <ActionAttributeDesignator AttributeId="action-id"/>
              </Apply>            
            </Condition>
          </Rule>
    
    
    2. HOW SAML ATTRIBUTES ARE CONVEYED AND REFERENCED
    
    XACML handles "authorization", not "authentication".  An X.509
    identity certificate is associated with "authentication".  It
    would be used by the web service's authentication mechanism
    (possibly federated) as a first step to determine that the
    subject making a request is who they claim to be.  Only after the
    service has done that step would XACML be invoked to check for
    the authenticated subject's authorization to do some particular
    action.
    
    So assume the book club web service has authenticated its subject
    as being "Anne H. Anderson".  It now wants to determine using its
    access control policy that Anne H. Anderson has permission to
    order the book with ISBN 0201787911
    
    Assume there is a SAML Attribute Assertion indicating that
    Subject "Anne H. Anderson" has the attribute "membership status"
    with a value of "member".  The web service trusts this attribute
    value since it has authenticated that the subject is "Anne
    H. Anderson".
    
    So the web service might extract this information and pass it in
    a SAML Authorization Decision Query to its XACML PDP.  [It
    requires a simple SAML extension to pass an XACML Request as a
    new type of SAML Authorization Decision Query.  An extension for
    this should be standard for SAML 2.0].
    
    Example:
    
    <saml:Query>
      <XACMLAuthorizationDecisionQuery>
        <xacml:Request>
          <Subject>
            <Attribute AttributeId="membership-status">
              <AttributeValue>member</AttributeValue>
            </Attribute>
          </Subject>
          <Resource>
            <Attribute AttributeId="ISBN">
              <AttributeValue>0201787911</AttributeValue>
            </Attribute>
          </Resource>
          <Action>
            <Attribute AttributeId="action-id">
              <AttributeValue>order</AttributeValue>
            </Attribute>
          </Action>
        </xacml:Request>
      </XACMLAuthorizationDecisionQuery>
    <saml:Query>
    
    Note that web service might pass the subject-id attribute of
    "Anne H. Anderson" to the XACML PDP, rather than the
    membership-status attribute.  This would work fine so long as the
    XACML PDP has access to the attributes for Anne H. Anderson (the
    XACML PDP may even make a SAML AttributeQuery back to the web
    service for an attribute value that it needs).  But either the
    web service's PEP or the XACML PDP side will have to obtain the
    SAML attribute assertion and extract the attribute identity and
    attribute value from the SAML assertion before using it in an
    authorization decision.
    
    3. HOW THE WEB SERVICE IS BOUND TO THE XACML ACCESS CONTROL POLICY
    
    The XACML profile for Web-services (WSPL) ways how this can be
    done: the policy is distributed in a WSDL service description
    "EndPointPolicy" element or in a SOAP header Policy element.
    
    The current WSPL specification is available at:
      http://www.oasis-open.org/committees/download.php/3661/draft-xacml-wspl-04.pdf
    
    4. HOW THE XACML ACCESS CONTROL POLICY IS BOUND TO THE WEB SERVICE
    
    The XACML profile for Web-services (WSPL) says how this can be
    done:
    
    In the XACML PolicySet, specify "access control" objective, the
    web service's WSDL portType, operation, and message as part of
    the XACML policy's Target.
    
    Example:
    
      <PolicySet>
        <Target> <!-- This PolicySet is for book-club-service:portX -->
          <Resources>
            <ResourceMatch MatchId="equal">
              <AttributeValue>book-club-service:portX</AttributeValue>
              <ResourceAttributeDesignator AttributeId="portId"/>
            </ResourceMatch>
          </Resources>
        </Target>
    
        <!-- sub-PolicySets may specify particular WSDL operations
             and operation messages within serviceX:portX.  In
             this example, the Policy for access control applies
             to ALL serviceX:portX operations and messages -->
    
        <Policy>
          <Target> <!-- This Policy is for access control -->
            <Actions>
              <ActionMatch MatchId="equal">
                <AttributeValue>access-control</AttributeValue>
                <ActionAttributeDesignator AttributeId="objectiveId"/>
              </ActionMatch>
            </Actions>
          </Target>
    
          <Rule Effect="Permit">
             <!-- this is where the policy rule above would go -->
          </Rule>
    
        </Policy>
    
        <!-- Other Policies for aspects of serviceX:portX other than
             access control may occur here -->
    
      </PolicySet>
    
    Anne Anderson
    -- 
    Anne H. Anderson             Email: Anne.Anderson@Sun.COM
    Sun Microsystems Laboratories
    1 Network Drive,UBUR02-311     Tel: 781/442-0928
    Burlington, MA 01803-0902 USA  Fax: 781/442-1692
    ------- end of forwarded message -------
    
    -- 
    Anne H. Anderson             Email: Anne.Anderson@Sun.COM
    Sun Microsystems Laboratories
    1 Network Drive,UBUR02-311     Tel: 781/442-0928
    Burlington, MA 01803-0902 USA  Fax: 781/442-1692
    
    


    [Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]