[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [xacml] Re: [sunxacml-discuss] XACML: Access Control for Web Services
Gary mentioned a link to relvant Liberty specs and Anne provided a link to the Liberty homepage. More specifically, the following is Liberty's Security Mechanisms spec (for which Gary is the editor) that defines how, as Gary puts it 'we schlep attributes around'. https://www.projectliberty.org/specs/draft-lib-arch-security-mechanisms-v1.0 -17.pdf >-----Original Message----- >From: Anne Anderson [mailto:Anne.Anderson@Sun.com] >Sent: Thursday, October 09, 2003 9:17 AM >To: Chiusana Joseph; sunxacml; XACML TC >Cc: Anne.Anderson@Sun.com; Gary.Ellison@Sun.com >Subject: [xacml] 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? > > > > 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". > >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: >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). > > > 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.p df > > 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 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 To unsubscribe from this mailing list (and be removed from the roster of the OASIS TC), go to http://www.oasis-open.org/apps/org/workgroup/xacml/members/leave_workgroup.p hp.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]