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


Help: OASIS Mailing Lists Help | MarkMail Help

xacml-dev message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Re: [xacml-dev] XACML obligations in SAML assertions??

Seth Proctor wrote:
> On Fri, 2005-03-25 at 11:01, Jackson Wynn wrote:
>>My query is based on the assumption that the PEP and PDP are separate, with
>>the PDP delivering a SAML Authorization Decision Statement to the PEP in the
>>following format:
>>Prior to SAML 2.0, no support was provided for conveying XACML responses as
>>SAML assertions. With the addition of XACMLAuthzDecisionStatementTypes in
>>v2.0, it became possible to forward the entire XACML response, including
>>obligations, to the PEP. How were XACML obligations conveyed to a PEP in
>>SAML 1.1? 
> I think the point is that before the SAML profile in XACML 2.0 there was
> no standard mechanism for conveying any XACML messages. In my
> experience, most people:
>   1. Did their own extension to SAML (similar to the profile)
>   2. Passed XACML Requests/Responses directly over a socket (etc.)
>   3. Used existing, app-specific formats and converted to a standard
>      format in the PDP service
>   4. Had their PEP and PDP tightly connected
> That's not an exhaustive list, but I think it covers the common cases
> (to others on this list: if you're doing something else that's
> interesting, chime in!).
> Bottom line, however, I haven't seen anyone trying to convey just
> Obligations in any system. Generally an XACML Response is what you're
> passing around, and if you figure out how to handle that, then you've
> also handled your Obligations.
We also had this problem how to map between XACML based policy 
decision and, in particularly, XACML Request/Response and our 
authorisation assertion that can be in proprietary format or using SAML.

Indeed, SAML 2.0 solution of simply encapsulating XACML Request and 
Response messages we see as a preferred option but current absence of 
available SAML 2.0 implementations is a problem.

So, our suggestion was to put Obligation information into one of two 
extendable SAML elements Conditions or Advice. But they are extendable 
in a different way.

The Condition element can contain extendable condition element as a 
specific named instance of the abstract Condition element. The Advice 
element can contain any extendable element using any external 
namespace. So, this may define your choice and preferences when you 
are using some specific SAML implementation like OpenSAML.

We modeled both options with OpenSAML but for practical purposes in 
the Collaboratory.nl project we use the Advice element to place the 
XACML Obligation element directly in.

I posted earlier two references where you can find more information 
about our solutions and also examples of SAML authorisation assertions 
with extensions in Conditions and Advice elements for obligations 

Using SAML and XACML for Authorisation assertions and messaging: SAML 
and XACML standards overview and usage examples.

Using XML based security tickets and tokens or SAML demystified - 

Hope this will be useful for others.



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]