[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