[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 information. Using SAML and XACML for Authorisation assertions and messaging: SAML and XACML standards overview and usage examples. http://www.uazone.org/demch/analytic/draft-authz-xacml-saml-02.pdf Using XML based security tickets and tokens or SAML demystified - http://www.uazone.org/demch/presentations/tf-emc2-authz-ticktok-2005.pdf Hope this will be useful for others. Regards, Yuri
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]