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

 


Help: OASIS Mailing Lists Help | MarkMail Help

xacml message

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


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 <tim.moses@entrust.com> on 2002/03/22 23:33

Please respond to Tim Moses <tim.moses@entrust.com>

To:   Michiharu Kudoh/Japan/IBM@IBMJP, XACML TC
      <xacml@lists.oasis-open.org>
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:KUDO@jp.ibm.com]
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>






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


Powered by eList eXpress LLC