Re: [xacml] New Issue#61: WS-XACML: How are the contents of XACMLAuthzAssertionsrepresented in the base XACML Policies

[Rich Levinson <rich.levinson@oracle.com>]

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*