RE: SAML does not support audit of assertion dependency between c o-operating authorities...

[Phillip Hallam-Baker <pbaker@verisign.com>]

Title: RE: SAML does not support audit of assertion dependency between co-op erating authorities...

Can the issue be addressed using the <AssertionRef> element discussed in the correspondence with Tim, placing the full assertion (if required) in the Advice section?

 

    Phill

Phillip Hallam-Baker FBCS C.Eng.
Principal Scientist
VeriSign Inc.
pbaker@verisign.com
781 245 6996 x227

-----Original Message-----
From: Carlisle Adams [mailto:carlisle.adams@entrust.com]
Sent: Monday, May 28, 2001 3:51 PM
To: 'Mishra, Prateek'
Cc: 'pbaker@verisign.com'; security-services@lists.oasis-open.org
Subject: RE: SAML does not support audit of assertion dependency between c o-op erating authorities...

Hi Prateek,

I thought this sort of linkage (i.e., assertion B back to assertion A) was at least one of the intents of the "Advice" element.  That is, a piece in the assertion that provides this sort of relevant or helpful background information but is explicitly a "non-critical extension" in that the verifier does not have to understand and process it in order to determine the validity of the assertion it is given (assertion B, in this case).

Carlisle.

----------
From:   Mishra, Prateek[SMTP:pmishra@netegrity.com]
Sent:   Monday, May 28, 2001 3:28 PM
To:     security-services@lists.oasis-open.org
Cc:     'pbaker@verisign.com'
Subject:        SAML does not support audit of assertion dependency between co-op erating authorities...




One issue with draft-sstc-core-07.doc is a lack of
support for audit of assertion dependency between co-operating
authorities. As one explicit goal of SAML was to support
inter-domain security (i.e., each authority may be
administered by a separate business entity)
this seems to be a serious "gap" in reaching that goal.

Consider the following example:

(1) User Ravi authenticates in his native security domain and receives
    Assertion A:

         <Assertion>
         <AssertionID>http://www.small-company.com/A</AssertionID>
         <Issuer>URN:small-company:DivisionB</Issuer>
         <ValidityInterval> . . . </ValidityInterval>
         <Claims>
            <subject>"cn=ravi, ou=finance, id=325619"</subject>
            <attribute>manager</attribute>
         </Claims>
      </Assertion>





(2) User Ravi authenticates to the Widget Marketplace using assertion A and
based
on the policy:
       
        All entities with "ou=finance" authenticated thru
     small-company.com with attribute manager have purchase limit $100,000

receives Assertion B from the Widget Marketplace:

        <Assertion>
        <AssertionID>http://www.WidgetMarket.com/B<AssertionID>
        <Issuer>URN:WidgetMarket:PartsExchange</Issuer>
        <ValidityInterval>. . . </ValidityInterval>
        <Claims>
           <subject>"cn=ravi, ou=finance, id=325619"</subject>
           <attribute>max-purchase-limit-$100,000</attribute>
        </Claims>
     <Assertion>




(3) User Ravi purchases farm machinery from a parts provider hosted at the
Widget Marketplace. The parts provider authorizes the transaction based on
Assertion B.

Even though Assertion B has been issued by the Widget Marketplace
in response to assertion A
(I guess another way to look at this to view assertion A
as the subject of B as in [1]) there is no way to represent this information

within SAML.

If there is a problem with Ravi's purchases at the Widget Marketplace (Ravi
wont pay
his bills) there is nothing in the SAML flow that ties Assertion B to
Assertion A. This
appears to be a significant missing piece to me.





- prateek mishra

[1]
http://lists.oasis-open.org/archives/security-services/200105/msg00152.html

------------------------------------------------------------------
To unsubscribe from this elist send a message with the single word
"unsubscribe" in the body to: security-services-request@lists.oasis-open.org

Phillip Hallam-Baker (E-mail).vcf