OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

xacml message

[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


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.


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.
>  >
>  >
>  > 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]