Hi Anne,
I just want to mention that I think the profile is a great document
and a really valuable example of how XACML can be applied.
I quickly looked over your suggestion and I think I must not have
expressed my point clearly.
What I am thinking is that these XACMLAssertions, both the
XACMLAuthzAssertion and the XACMLPrivacyAssertions are
elements that can be included in a ws:Policy elements and used
in wsdl and other policy containers to express the requirements
to clients as to what they need to do to successfully access the
web service. I think we probably agree on that, and, if so, then
I can get to what the issue is that I am considering.
I would expect (correct me if I am wrong, but this is what I am
thinking) that it is perfectly reasonable, if not likely, that these
XACMLAssertions will be part of an overall xacml architecture
in various enterprise environments. As such, it is likely that
there are one or mores PDP out there in the enterprise that are the
home of a collection of xacml policies, as well as being the decision
points handling PEP requests.
It is also my expectation that this PDP (or at least the people who
adminster the PDP) will likely consider the Web Services to be
Resources that its policies in general will cover.
So, I put myself in the position of one of these PDP admins and
ask myself, how do I create a XACML Policy that will contain all
the info I want to govern the access to this web service Resource
(as suggested by the para 2 in section 4, etc.). What I am thinking
is that only a subset of this info should go to the XACMLAssertions,
which will end up in the wsdl, but the rest of the info I want to keep
private and just use at runtime to validate and authorize requests and
produce Responses etc.
So, the question is: how do I flag the subset of XACML Policy info
that is targeted for the XACMLAssertions - I guess I am also assuming
that the WebService Manager, in whatever form it will take, will in
general make a XACMLRequest to the PDP to get the Policy or
Policies governing this Resource. That Manager would then need to
be able to select from the XACML Policy (as opposed to the WS Policy,
which, on the other hand, the Manager is populating for setup etc.) the
elements:
<element ref="xacml:Policy" minOccurs="0" maxOccurs="1" />
<element ref="xacml:PolicySet" minOccurs="0" maxOccurs="1" />
<element ref="xacml:Apply" minOccurs="0" maxOccurs="unbounded" />
<element ref="xacml-context:Request" minOccurs="0" maxOccurs="1" />
that can be moved from the xacml:Policy data to the Capabilities and
Resources
elements of the XACML*Assertion.
So, I am wondering what the original xacml:Policy, which I assume can
contain
the source elements for these XACML*Assertions, will look like and how
one
would go about selecting the appropriate info therefrom.
Bottom line is that the examples you suggested below, appear to me to
be the
final step of this process: i.e. some entity has put these ws:Policy
blocks as
part of the wsdl or other that the client encounters before making the
actual
access. To use your first example:
<Requirements>
Has signed license agreement
</Requirements>
I would expect that somewhere in the PDP policy store that a
xacml:Attribute
might exist with an AttributeValue: "Has signed license agreement", and
that
when one queries the PDP for this xacml:Policy that they are able to
obtain this
AttributeValue and put it in the Requirements element of the ws:Policy.
OK, so now hopefully that explains how I am looking at this and maybe
there
is some complete aspect to this that I am missing, that will help
explain it all.
Thanks,
Rich
Anne Anderson - Sun Microsystems wrote:
Hi Rich,
Thanks for the feedback.
Rich Levinson wrote On 12/15/06 14:05,:
61. WS-XACML: How are the contents of XACMLAuthzAssertions
represented in the base XACML Policies
(Submitted by: *Rich*)
Reading the spec, it appeared to me that an important piece of info
might be missing (or either I missed it or it intentionally is not
there, but that's the point of this issue). As an entry point to this
potential issue, consider statement in Section 4, p 23, para 2, that
says
"For security reasons, many entities are unwilling to publish their
complete authorization and access control policies. Therefore, an
XACMLAuthzAssertion </xacml/AuthzAssertion> MAY not be a complete
specification of an entity's authorization and access control policy. A
service MAY choose to publish all or a subset of the XACMLauthorization
or access control policy it will apply with respect to particular
policy targets."
How are the subsets of the core xacml policies identified as to what
should and should not be made public?
It is completely site-dependent as to what is published and what isn't.
Particular trade/service communities (on-line bookstores, etc.) might
standardize policy vocabularies to be used in stating
XACMLAuthzAssertions or XACMLPrivacyAssertions for their sites.
As an example, Sun certainly isn't going to publish its enterprise
policy. But consider some fictitious software download site maintained
by Sun; for this site, Sun might publish the following:
<wsp:exactlyOne>
<XACMLAuthzAssertion>
<Requirements>
Has signed license agreement
</Requirements>
<Capabilities>
Provide trial version
</Capabilities>
</XACMLAuthzAssertion>
<XACMLAuthzAssertion>
<Requirements>
Has signed license agreement
Has paid for Level 3 support
</Requirements>
<Capabilities>
Provide current production version
</Capabilities>
</XACMLAuthzAssertion>
</wsp:exactlyOne>
Would it help to include an example like this?
Also, it would be of interest to
see some example policies that contained
entities that end up in the Capabilities and Requirements sections of
the Assertions. I am particularly interested in how privacy
requirements might be set up in the original policy since these are
generally not part of the authorization process, per se', but possibly
could be considered to be modelled as XACML Obligations. Any guidance
on this in reply to issue or changes to doc would be much appreciated.
Consider a service policy saying the service will provide a copy of its
current price list if the client agrees to retain it no longer than 30
days and not to disclose it to 3rd parties. The service also says it
will not disclose the client's personal information to 3rd parties.
<XACMLPrivacyAssertion>
<Requirements>
max-data-retention-days <= 30
data-disclosure == "ours" }
</Requirements>
<Capabilities>
resource-id="current-price-list"
//p3p10full/POLICIES/POLICY/RECIPIENT/* subset-of { "ours" }
</Capabilities>
</XACMLPrivacyAssertion>
A client policy might say:
<XACMLPrivacyAssertion>
<Requirements>
resource-id="current-price-list"
//p3p10full/POLICIES/POLICY/RECIPIENT/* subset-of { "ours" }
</Requirements>
<Capabilities>
max-data-retention-days <= 30
data-disclosure == "ours" }
</Capabilities>
</XACMLPrivacyAssertion>
There is another example using XACML's XML syntax in Section 6 of WD 8.
Is this what you are looking for? If you could describe ways in which
the examples in Section 6 are inadequate, I could provide more examples
or better examples.
Status: *OPEN*
