Colleagues,
My thinking evolved considerably during the development of the draft I
posted yesterday. Some major changes since I posted my earlier
suggestions about this profile (Issue#47) on the XACML mailing list are:
- There is no XACMLPolicyAssertion. An XACMLAuthzAssertion now covers
the functionality of both types of Assertions. This solves a problem in
matching Assertions, since the two types previously could express the
same type of assertion information.
- A WS-Policy alternative may contain only one XACMLAuthzAssertion -
previously, I had envisioned multiple "Apply" elements in separate
XACMLAuthzAssertions. Instead, the single XACMLAuthzAssertion may
contain multiple "Apply" element, a Policy, a PolicySet, or a Request.
This also addresses the problem of matching XACMLAuthzAssertions between
two WS-Policy instances.
- An XACMLAuthzAssertion contains two parts: Requirements and Capabilities.
o Requirements are constraints the other party must satisfy; they
correspond to XACML policies, although they may also be represented by a
sequence of "Apply" elements (equivalent to a Condition containing an
"AND" of the sequence of "Apply" elements).
o Capabilities are information a party is able and willing to provide
to satisfy requirements of another party; they correspond to XACML
requests, although they also may be represented by a sequence of "Apply"
elements ("I am willing and able to provide any value from this set for
the Attribute 'role'").
- XACMLAuthzAssertions from two WS-Policy alternatives match if the
Requirements of each are satisfied by the Capabilities of the other.
The reason for the asymmetry is to fit the XACML model: a client may
present many more Attributes in its Request than the service needs to
satisfy its policy.
- Both clients and services (consumers and providers) may have
Requirements and Capabilities. Client Requirements are especially
important for privacy policies ("you must delete any personal
information I provide within 30 days").
- Obligations must be represented as constraints on Attributes that
represent the Obligation, like any other Attribute constraint. A party
will include a value or constraint function in its Capabilities for the
Obligations it is able and willing to fulfill. A party will include a
constraint function in its Requirements for Obligations it requires the
other party to fulfill. Again, this is important for privacy policies
in particular.
- There is no longer an XACMLAuthzCredential. I realized the existing
SAML Assertion containing an XACMLAuthzDecisionStatementType instance
serves that purpose, so I simply described this use.
- I added a section on some ways a client might provide Attributes to
the service in a SOAP Security header as part of the Web Services
message. These are not new formats, just descriptions of the use of
SAML Attribute Assertions or XACMLAuthzDecisionRequests for this purpose.
Regards,
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