OASIS eXtensible Access Control Markup Language (XACML) TC

Re: [xacml] Issue#47: XACML WS-Policy Assertions name problem

  • 1.  Re: [xacml] Issue#47: XACML WS-Policy Assertions name problem

    Posted 10-11-2006 15:11
    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