[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [xacml] Issue#47: XACML WS-Policy Assertions name problem
Hi Tony, Anthony Nadalin wrote On 10/10/06 01:28,: > So what do you think the use cases are ? I have a list of use cases in the Introduction section of WD 5, which I submitted yesterday: Web Services Profile of XACML (WS-XACML) Version 1.0, WD 5, 9 October 2006 http://www.oasis-open.org/committees/download.php/20643/xacml-3.0-profile-webservices-spec-v1.0-wd-5-en.pdf It is linked off the XACML TC Home Page under "Work in Progress", replacing the old WSPL link, since this is the successor to WSPL. > How are policies fetched ? I'm not sure I understand the question. A service fetches its policies from its database, or wherever it stores them, and they are inserted into the XACMLAuthzAssertion just as other service-specific information is fetched and stored into other WS-Policy Assertions. This is for relatively stable authz policies, where the policy can be put into a WS-Policy instance and updated only as often as other information in the WS-Policy instance might be updated. I don't think anyone has designed a standard way for clients to store and fetch their authz policies. That is up to the client. > Do you see the usage mainly being a policy store -> PDP ? No. I see it as a service taking the policy it's PDP will use (or a subset of it) and publishing it for the use of clients in deciding whether and how to connect with the service. It is not a policy provisioning mechanism at all. > How would I include policy in a request (to cover a bootstrap case, I would imagine > I would want this in a token). In the new version of the SAML Profile for XACML 3.0, we allow a policy to be included in an XACMLAuthzDecisionRequest. Such a request could be included in a SOAP Security header like any other token. Perhaps I should include that in the next draft of the Profile. Regards, Anne > > Anthony Nadalin | Work 512.838.0085 | Cell 512.289.4122 > Inactive hide details for Anne Anderson - Sun Microsystems > <Anne.Anderson@sun.com>Anne Anderson - Sun Microsystems > <Anne.Anderson@sun.com> > > > *Anne Anderson - Sun Microsystems > <Anne.Anderson@sun.com>* > > 09/14/2006 10:10 AM > Please respond to > Anne.Anderson@sun.com; Please respond to > Anne.Anderson@sun.com > > > > To > > XACML TC <xacml@lists.oasis-open.org> > > cc > > > Subject > > [xacml] Issue#47: XACML WS-Policy Assertions name problem > > > > > [this is a resend with a more descriptive Subject line] > > Here are some thoughts on the problem of how to deal with the Assertion > Type of an XACMLPolicyAssertion, XACMLAuthzCredential, or an > XACMLAuthzAssertion. The problem is how a client should match the > client's policy or implicit policy against the service's policy where > these XACML Assertions are used. "The policy assertion type is > identified only by the XML Infoset [namespace name] and [local name] > properties (that is, the qualified name or QName) of the root Element > Information Item representing the assertion. Assertions of a given type > MUST be consistently interpreted independent of their policy subjects." > > Again, the three proposed new Assertion types are: > > - XACMLPolicyAssertion: contains an entire XACML Policy or PolicySet > representing the authorization or access control policy that a service > wishes to publish externally. It may well be a subset of the actual > policies used internally. We would specify that no more than one > XACMLPolicyAssertion can be used in a single WS-Policy alternative (one > acceptable combination of Assertions). > > - XACMLAuthzCredential: contains an XACML authorization decision in the > form of a SAML Assertion containing an instance of an > XACMLAuthzDecisionStatementType. The instance should contain the > associated Request Context in order to provide the proper context for > the decision. This Assertion is used to either require or provide an > authorization token or credential that is in the form of an XACML > authorization decision. > > - XACMLAuthzAssertion: a constraint on an individual authorization > vocabulary element in the form of an XACML <Apply> element. A set of > these would be used to express simple authorization requirements. > > PROPOSED MATCHING SOLUTIONS > > 1. XACMLPolicyAssertion: I don't think this is a problem. The format > can allow an empty XACMLPolicyAssertion for use by a client indicating > that the client is willing to conform to an XACML Policy. The generic > policy processor would match only on the type <XACMLPolicyAssertion>. > It would be up to the client to decide how to use the service's policy > instance. Since we would allow no more than one XACMLPolicyAssertion > per policy alternative, there is no need to merge or combine multiple > Assertions of this type. > > 2. XACMLAuthzCredential: I also don't think this is a problem. Again, > the generic policy processor would match only on the type > <XACMLAuthzCredential>. A service could specify an empty > XACMLAuthzCredential to indicate the service requires this type of > credential, or a full XACMLAuthzCredential indicating that for a request > containing the included Request Context Attributes, the service will > require an XACMLAuthzCredential signed by a trusted PDP (WS-Trust might > be used to negotiate these). If a client has multiple > XACMLAuthzCredentials, that is the same as having multiple instances of > any other type of credential - it is up to the service's domain-specific > Assertion handler to deal with specific matches. > > 3. XACMLAuthzAssertion: The matching would use the semantics currently > defined in our WSPL Working Draft, from which we would copy. The > profile would recommend that the FunctionIds used be from the WSPL set. > The generic policy processor would simply verify that a policy > alternative from each party contains at least one instance of an > XACMLAuthzAssertion and would pass the entire set of XACMLAuthzAssertion > elements in each policy to the domain-specific XACML Assertion processor > for detailed matching. The XACML Assertion processor would match the > elements in two different policies using the table of matching semantics > we would copy from the WSPL Working Draft. > > There are at least two ways we might express the "type" of an > XACMLAuthzAssertion for matching purposes: > > a. Express these Assertions in the form <xacml:Apply ...> (i.e. standard > XACML syntax). The generic policy processor would just verify that each > policy alternative has at least one instance of an XACMLAuthzAssertion, > and pass them to the domain-specific XACML Assertion processor to sort > out. WS-Policy states "A policy alternative MAY contain multiple > assertions of the same type. Mechanisms for determining the aggregate > behavior indicated by the assertions (and their Post-Schema-Validation > Infoset (PSVI) content, if any) are specific to the assertion type and > are outside the scope of this document." > > b. Express these Assertions in a form that creates an Assertion type > from their AttributeId or AttributeSelector value. This would allow the > generic policy processor to do one more level of Assertion matching. > > We could put a wrapper around the <xacml:Apply> that contains the > Assertion type information, or could supply XSLTs that transform an > <xacml:Apply> to the form <...AttributeId... DataType=".." > FunctionId=".."> with either an AttributeValue or another AttributeId > inside. In other words, the AttributeId would be converted into the > type of the XACML Assertion in some standard way. Where there are two > AttributeIds in the <Apply> instance (for example, requiring one > authorization value to be greater than another, perhaps two Assertions > would be created, each with the type of one of the AttributeIds. > > For AttributeSelectors, we would need a way to map an XPath identifier > onto Assertion types, and this may be a bigger problem. Could this be > done by creating a unique xmlns id > (random#?) in the header, setting it equal to the XPath expression, and > then using just the id in the Assertion? Can an Assertion have no > [local name]? Or could take last digit of id as [local name]. > > Anne > -- > 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 > From - Wed > > -- 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]