SAML and XACML Intersection

In the interest of facilitating the merger of XACML a pre-TC effort into the SAML TC at a future date or the ongoing interoperability of the work products from two separate TCs I am watching for the points of intersection and will post them for discussion to both lists as I identify them. Here is the first:

Particularly relevant to the interoperability of SAML with XACML is the nature of these two items extracted from the draft SAML requirements document:

[R-AuthN] SAML should define a data format for authentication assertions, including descriptions of authentication events. This includes time of authentication event and authentication protocol.

[R-AuthZ] SAML should define a data format for authorization attributes. Authorization attributes ("authz attributes") are attributes of a principal that are used to make authorization decisions, e.g. an identifier, group or role membership, or other user profile information.

Greg Wilson’s recent comments are illuminating:

I suspect that what Prateek means when he says "standardise credentials" is _not_ "standardise how SAML implementations are required to assign trust to credentials", but rather "standardise how to describe what sort of credentials were presented". The second form is necessary in order to make policy decisions such as "Allow <subject> to <verb> <object> only if they

logged in using an X9.9 Challenge-Response."

XACML will definitely require a standardized and very extensible way of representing name assertions since it is almost impossible for us to predict what type of information is required to make a policy decision. I think this is evidenced by the fact that so much policy information today is embedded in application code. Externally defined, inflexible, and non-extensible security mechanisms have been failing application developers for some time with respect to the implementation of access control policies that reflect business or regulatory requirements.

XACML must be designed to be compatible with the data formats for authentication assertions and authorization attributes. However, that does not mean we should wait for these items to be finalized prior to proceeding with XACML work since SAML must also provide to XACML a data format that is sufficiently extensible and expressive to be used within the context of XACML. Even is SAML does not dictate how trust is assigned a policy engine receiving information from an authentication service must be able to assume that the information is trusted, or have it flagged as otherwise … hmm … this brings up another possible requirement for SAML.

Should SAML facilitate the passing of assertions in such a manner that they are annotated with some level of trust? If this does not occur, we will be in the potentially awkward situation of having to pipe information to a policy server through two different channels.

Simon Y. Blackwell

CTO

Psoom, Inc.

Voice & Fax: 415-762-9787

security-services message