[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
Tony, Thanks for the rapid review! p.2 [for use with WS-Policy] "I assume WS-PolicyAttachment also": I did not mention WS-PolicyAttachment because I was not aware that Assertions, Security Tokens, or Attributes appeared in WS-PolicyAttachment independently of WS-Policy. Is there a dependency I should be aware of? p2 [client and service requirements?] "So today the emhasis of WS-Policy is on the service not the client" This profile could be used just to specify service assertions, but it also supports client assertions, because those are important to the XACML domain. p2 "What are "authenticated attributes" ? are these the same things as "claims" as described in WS-Security?": These are SAML or XACML Attributes that a Context Handler trusts because they are known to have been issued by a trusted attribute authority. p2 "I don't quite understand a "internal XACML policy"": this is the policy an enterprise actually uses to control access to its internal resources, i.e. what XACML has been used for traditionally. Such a policy is often not exposed, at least not in its entirety, to clients for security and confidentiality reasons. I am assuming that XACMLAuthzAssertion instances will be exposed as part of the Service's WS-Policy instances. p5 [WS-Security and authorization tokens] "Actually these are for security tokens we don't distinguish between token usages": I will change this. The actual tokens specified in WS-Security all seem to be related more to authentication, however, so I am trying to point out the use for this new token. p5 [authorization tokens] "Not sure that a UsernameToken can't be used for Authentication or Authorization, etc. So need to understand what you are trying to say here.": I will change the reference to WS-Security as specifying only authentication tokens. This XACML token, however, is very different from a UsernameToken - it represents an authorization decision, not an identity. p5 "It looks like this profile first attempts to define a new type of token assertion that needs to be recognized and then goes on to talk about the assertions.": I will try to clarify that the profile defines three independent aspects of how XACML might be used in a Web Services context: 1) a way to use an XACMLAuthzDecisionStatementType instance as an authorization token, 2) a new Assertion for specifying policies, 3) ways to convey Attribute values that a service PDP's Context Handler might use in evaluating XACML policies related to a Web Services message. p5 [Another Web Service may operate on a constrained device that is unable to run a Policy Decision Point] "This assumes that end points have a notion of identity, which is not the case today": I don't understand the connection. p5 [XACML authorization token] "I assume that this would be in addition to other tokens": Yes. p5 [service verifies that the token correctly describes the controlled access that the client invocation requires] "I also assume that the endpoint also has a policy that it must intersect with the client's policy": Usage of this authorization token and use of policies in XACMLAuthzAssertions are independent. Neither the client nor the service may have published an authorization/access control/privacy policy, but the service might still use an authorization token. Publishing a policy that states that an authorization token is required would be one way for a service to let a client know of this requirement; and a client capable of supplying an authorization token could state this in its policy; but neither is required. p5 [client obtains Attributes ... to convey to the Web Service] "So do we assume that these attributes would take the form of policy". No. I think I created some confusion by not making it more clear at the beginning that this profile addresses three completely separate aspects of usage of XACML in a Web Services context. I will clarify this in the next draft. p5 [service includes a requirement in its published Web Services policy] "So you would expect this to be a policy intersection ?" No. At this point it is just a policy that includes this requirement among possibly others. An intersection could be performed between this service's policy and various potential client policies as part of a decision to participate in a Web Services interaction, however. p6 [to see if the request is likely to be authorized when the service is invoked] "I assume that this is at any level of the service, that is at the various WSDL subject levels": Yes. It will apply to requests associated with the attachment point of the WS-Policy instance of which the XACMLAuthzAssertion is a part. p6 [how to use XACML SAML Assertions in the context of Web Services] "So why just SAML, why not have a new token type that just has claims? Keeping claims in normalized form separately from tokens allows consumer to not have to support multiple token": Because the SAML Assertion has already been defined, and other SAML Assertions appear to be in use as tokens. If there are accepted guidelines against this, and accepted guidelines for how authorization claims would be formulated, I would be happy to revisit this. p8 [how to use a SAML Assertion containing an XACMLAuthzDecisionStatementType instance as a token] "So this would have to be profiled somewhere, somehow. Also it seems that we would not wnat to have to dig into the assertion to figure out that this is a "authorization" token": I assume that services that require such an authorization token would specify this requirement as part of their documentation, and possibly as part of their XACMLAuthzAssertion. I saw another instance of a SAML Assertion being used as a token, so followed that lead. I agree that it would be nice to know what type of token it is, but since you point out that WS-Security defines "security" tokens, and does not distinguish between "authentication" and "authorization" tokens, it may be too late to try to create an element name distinction now. p8 [client MAY use token to convey an authz decision from a trusted 3rd party to a Web Service] "Endpoints may also need these tokens": I need more education on "endpoints", as opposed to clients and services in a SOAP message exchange, and targets or subjects of WS-Policy instances. I would be happy to broaden the applicability description. p9 [Web Service MAY choose to publish ... XACML ... policy it will apply with respect to a particular Web Service target] "So how is this done, via WS-PolicyAttachment ? I would imagine that we would want a interoperable way to reference policy. So is this a service wide policy? How do I subset the policy as these can be very large?": This is only used as an Assertion in a WS-Policy instance. So however the WS-Policy instance is used is how this Assertion would be used to publish the policy. It should be the policy that applies to the target/subject associated with the WS-Policy instance of which it is a part. p9 [Two instances of XACMLAuthzAssertion MAY be matched to determine whether they are compatible, and, if so, which requirements and capabilities are compatible] "intersected": Yes, intersection is the way they are matched. I was trying to start out without having to explain intersection, but if you think this would be more clear at this point in the presentation, I would be happy to change or add this. p9 [XACMLAuthzAssertion/Requirements/, XACMLAuthzAssertion/Capabilities/] "Why are these elements and not attributes ?" Because the content of the two has different forms, and because I want a single XACMLAuthzAssertion in any given WS-Policy alternative that can be matched against the single XACMLAuthzAssertion in any other WS-Policy alternative (at the level of recognition that an XACML policy is involved) without the generic policy engine having to match domain-specific attributes. p9 [There SHALL be no more than one XACMLPolicyAssertion included in any one wsp:Policy alternative] "Why this limitation as this will lead to having way too many policies": In most cases, I expect the policies using the <Apply> element format in XACMLPolicyAssertions to be fairly basic, without a lot of options. If the policy target needs a complex policy, then the service would use the <Policy> or <PolicySet> format. Having only one Assertion of this type per alternative means the generic policy engine can match two policy alternatives so long as both contain an instance of an XACMLPolicyAssertion, and let the domain-specific processor handle the internal matching. p10 [An XACMLAuthzAssertion that contains no Requirements ... indicates that the entity publishing the XACMLAuthzAssertion has no ... requirements ... that it is willing to publish] "So it's still unclear that these (a null vs. an empty) will match": They are equivalent, so they do match. I will be more clear about this. p12 [two XACMLAuthzAssertions match if all the Requirements of each entity are satisfied by the Capabilities of the other entity] "I'm not sure that this will scale as it's hard to have a single policy": If a single policy (i.e. a sequence of <Apply> elements, all of which are required) is insufficient, then the service should use the Requirements/Policy or Requirements/PolicySet format, although these can be matched only against a Capabilities/Request format. p13 [Intersection of two Apply elements] "This now assumes that the framework intersection is not used, which pushes this to the domain provider": Correct. It was my understanding that the generic policy processor that performs framework intersection matches only on Assertion QNames, and not on the specific content of the Assertions, so this must be a frequent occurrence except where Assertions are simple one-word information items. p15 [including XACML Attributes in a Security SOAP Header] "How would these be included in the header, only in a SAML token ?" By including the SAML Assertion as an element instance in the Security Header. I've seen other instances of including SAML Assertions as ways of conveying security information in the Security Header, so I'm not sure I understand the problem. Regards, Anne Anthony Nadalin wrote On 10/11/06 06:11,: > Anne, > > Here are my comments on your draft (as pdf markups) > > /(See attached file: > xacml-3.0-profile-webservices-spec-v1.0-wd-5-en-ajn.pdf)/ > > 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]