[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/11/06 04:22,: > >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. > > There are several ways, one is defined in WS-PolicyAttachment, others > include WS-MetadataExchange, why I > ask this question is because its going to be important how assertions > are declared as I want to be > able to fetch based upon fragments and not the whole policy documents. The XACMLAuthzAssertion will be a single Assertion included in a WS-Policy instance alternative. I don't want to define how a client or service must obtain the policies that are included in its XACMLAuthzAssertions. Once an XACMLAuthzAssertion is in a WS-Policy instance alternative published by the service (or client), you can fetch the Assertion or any part of it using XPath. 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>* > > 10/10/2006 09:33 AM > Please respond to > Anne.Anderson@sun.com > > > > To > > XACML TC <xacml@lists.oasis-open.org> > > cc > > > 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 > -- 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]