RE: [xacml] Proposed resolution from PM-8-05

Title: RE: [xacml] Proposed resolution from PM-8-05

Michiharu - Yes.  You are perfectly right ... a <saml:Condition> element is a child element of a <saml:Assertion> element, not a <saml:AuthorizationDecisionStatement>.  If we allow multiple decisions per assertion, then <saml:Condition> is not a suitable place for our <xacml:obligations> element.  Therefore, I agree with you proposal.  All the best.  Tim.

-----------------------------------------

Tim Moses

Tel: 613.270.3183

-----Original Message-----

From: Michiharu Kudoh [mailto:]

Sent: Sunday, March 24, 2002 9:41 PM

To: XACML TC

Subject: RE: [xacml] Proposed resolution from PM-8-05

Hi, Tim

At first, I thought about using SAML Condition element to carry obligation

decision as you suggested. If the obligation (stored in the condition

element) means that PEP must understand (support, be able to fulfill, etc.)

the obligation, it will be fine. But I am not sure that is a right

interpretation of the definition statement of "each condition 'evaluates'

to a status of Valid, Invalid, or indeterminate". It seemed to me that if

we put obligations in the element something like <PEPMustUnderstand> (very

strange) in the condition element, such implication (must understand)

becomes much more explicit in comparison with predefined conditions such as

"NotBefore" and "AudienceRestrictionCondition".

Another problem I had is related to the XML resource protection application

example I posted on the list before the F2F#4.

http://lists.oasis-open.org/archives/xacml/200203/msg00024.html

In the section 2.1.3, I described the case where the authorization request

asks the access to more than one target element. For example, if the target

resource of the authorization request is specified like "//email" (a

requester wants to access every email element without specifying each

name), it potentially means multiple authorization requests. The resultant

authorization response might contain multiple authorization decision

assertions (SAML allows to have multiple authorization decision assertions

in one SAML response but allows only one conditions element in SAML

response):

  grant access to /record/patient/patientContact/email

  deny access to /record/insurer/email

which may be stored in one SAML response (this would be an issue, too).

Moreover, the first decision and the second decision may have different

obligations:

  grant access to /record/patient/patientContact/email, obligation is

"notification to the patient"

  deny access to /record/insurer/email, obligation is "log"

Having considered above cases, I thought having an obligation element in

the authorization decision statement is more flexible. Anyway, I raise a

new issue "Multiple authorization decision assertions in a SAML response".

Best

Michiharu Kudo

IBM Tokyo Research Laboratory, Internet Technology

Tel. +81 (46) 215-4642   Fax +81 (46) 273-7428

From: Tim Moses <> on 2002/03/22 23:33

Please respond to Tim Moses <>

To:   Michiharu Kudoh/Japan/IBM@IBMJP, XACML TC

      <>

cc:

Subject:  RE: [xacml] Proposed resolution from PM-8-05

Michiharu - I was thinking that xacml obligations properly belong in the

"conditions" element of a saml authorization decision assertion.  Here is

the schema fragment (from saml v28).

        <element name="Conditions" type="saml:ConditionsType"/>

        <complexType name="ConditionsType">

                <choice minOccurs="0" maxOccurs="unbounded">

                        <element ref="saml:Condition"/>

                        <element ref="saml:AudienceRestrictionCondition"/>

                </choice>

                <attribute name="NotBefore" type="dateTime" use

="optional"/>

                <attribute name="NotOnOrAfter" type="dateTime" use

="optional"/>

        </complexType>

        <element name="Condition" type="saml:ConditionAbstractType"/>

        <complexType name="ConditionAbstractType" abstract="true"/>

Condition is an abstract type that xacml must extend in order to

accommodate obligation.  The significance of a saml condition is that, if

the recipient does not understand the contents, then it MUST reject the

assertion, i.e. deny access.

All the best.  Tim.

-----------------------------------------

Tim Moses

Tel: 613.270.3183

-----Original Message-----

From: Michiharu Kudoh [mailto:]

Sent: Friday, March 22, 2002 3:54 AM

To: XACML TC

Subject: [xacml] Proposed resolution from PM-8-05

I would like to propose a resolution as follows:

-ISSUE: PM-8-05: How to return obligation via SAML

Here is an authorization decision syntax that returns obligation(s). SAML

AuthorizationDecisionStatement is extended to include xacml:obligations

element by type extension. "samle" namespace prefix is used to indicate

SAML extension for the decision assertion with obligation. Note that the

following example just shows the overview for simplicity.

<saml:Assertion>

  <saml:AuthorizationDecisionStatement Resource="aaa" Decision="Permit"

xsi:type="samle:AuthorizationDecisionStatementWithObligations">

  <saml:Subject>

   <saml:NameIdentifier SecurityDomain="aaa" Name="Alice"/>

  </saml:Subject>

  <saml:Actions Namespace="http://www.oasis-open.org/xmlactions">

   <saml:Action>Read</saml:Action>

  </saml:Actions>

  <xacml:obligations>

   <xacml:obligation obligationId="myId">

     ...

   </xacml:obligation>

  </xacml:obligations>

  </saml:AuthorizationDecisionStatement>

</saml:Assertion>

The following "samle" schema fragment defines an authorization decision

with obligations.

<complexType name="AuthorizationDecisionStatementWithObligations">

  <complexContent>

    <extension base="saml:AuthorizationDecisionStatementType">

      <sequence>

        <element ref="xacml:obligations"/>

      </sequence>

    </extension>

  </complexContent>

</complexType>

Michiharu Kudo

IBM Tokyo Research Laboratory, Internet Technology

Tel. +81 (46) 215-4642   Fax +81 (46) 273-7428

----------------------------------------------------------------

To subscribe or unsubscribe from this elist use the subscription

manager: <http://lists.oasis-open.org/ob/adm.pl>

----------------------------------------------------------------

To subscribe or unsubscribe from this elist use the subscription

manager: <http://lists.oasis-open.org/ob/adm.pl>