OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

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

I am forwarding some elaborative comments on my explanation
provided by Gary Ellison, a Liberty expert.  I have inserted his
comments in-line below.

Ellison: I think your reply is excellent. I do have a few comments (inline)
Ellison: mostly from a Liberty (Identity Web Services) perspective regarding #2.

On 7 October, Anne Anderson writes: Re: [sunxacml-discuss] XACML: Access Control for Web Services
 > 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?
 > 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>
 > 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".

Ellison: Where did this Attribute Assertion come from. In the original
Ellison: invocation of the book club web service? Or does the book club web
Ellison: service construct the assertion and use it to interact with the XACML
Ellison: PDP? In a the WSS-SAML profile this would be accomplished by having the
Ellison: book club web service (BCWS) constructing a soap message to the PDP with a
Ellison: security token stuffed in the header. The BCWS would vouch for "Anne
Ellison: H. Anderson" in the assertion. Of course BCWS would have to authN to
Ellison: the PDP before giving an answer.
 > 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.

Ellison: FWIW, in Liberty ID-WSF, we (unforutnately) do not use
Ellison: AuthZDecisionQueries nor AttributeStatements (with one exception) for
Ellison: schlepping around attributes. 
Ellison: If you are interested I can point you to the latest (rather large)
Ellison: body of specs.

Anderson: See Liberty Alliance Project (http://www.projectliberty.org).

 > 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
 > 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 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]