[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: First contact
-----Original Message-----
From: Jahan Moreh [mailto:jmoreh@sigaba.com]
Sent: Thursday, July 26, 2001 4:10 PM
To: 'Tim Moses'; 'OASIS SAML'
Subject: RE: First contactI certainly agree that "..a relying party must be able to confirm that it [bearer token] was issued by an authority that it trusts to the entity that is presenting it.". However, I disagree with the statement that "...supplementary communication between the relying party and the issuer is needed to confirm this". There are other techniques one can employ to challenge the bearer of the token to prove that it was the original and intended recipient of the token.Thanks,Jahan---------------------------
Jahan Moreh
Chief Security Architect
Sigaba Corp.
jmoreh@sigaba.com
cell: 310.890.9391
tel: 310.286.3070-----Original Message-----
From: Tim Moses [mailto:tim.moses@entrust.com]
Sent: Thursday, July 26, 2001 1:01 PM
To: OASIS SAML
Subject: RE: First contactAnders - It is a mistake to think of the SAML artifact as an unfortunate compromise imposed on us by the limitations of commercial browsers. It is the "bearer token" in SAML's Web browser authentication scheme. If you have it, you can impersonate the subject of the associated assertion. Therefore, a relying party must be able to confirm that it was issued by an authority that it trusts to the entity that is presenting it. So, supplementary communication between the relying party and the issuer is needed to confirm this, not merely to get additional information that wouldn't fit into the artifact. Without this supplementary communication, one relying party can impersonate any subject that it has previously authenticated.
Best regards. Tim.
-----Original Message-----
From: Anders Rundgren [mailto:anders.rundgren@telia.com]
Sent: Thursday, July 26, 2001 4:11 AM
To: OASIS SAML; Tim Moses
Subject: Re: First contact
First contactHi Tim,
I appreciate discussions in this area as I feel that there are some less
clear things in SAML! Anyway, some comments in-line.>Push model
>Browser Content site Authentication site
>1 <----------- redirect----------
>2 -------------redirect----------------------------------->
>3 <-------------------------authenticate------------------>
>4 <-------assertion-------
>5 --------reference------>
>6 <-----------------------------------redirect(reference)--
>7 --------redirect(reference)--->>The Push model leaves questions like ...
>How does the Authentication site know where to send the assertion?By having the redirect in #1-2 contain this information
>How does the Authentication site know what attributes to include in the assertion?
By having the redirect specify what it wants, and let the user or the
user's authority do some choices. Shibboleth use-case>Furthermore, the authentication thread is occupied waiting for the reference to return from the Content site.
This is indeed a problem. The easiest solution is to not use
references but entire assertions:http://www.x-obi.com/OBI400/andersr-browser-artifact.ppt
>In both cases, the Content site has no opportunity to indicate its authentication
>requirements (one or two factor, for instance).It has that in the redirect.
Regards
Anders Rundgren
X-OBI
------------------------------------------------------------------
To unsubscribe from this elist send a message with the single word
"unsubscribe" in the body to: security-services-request@lists.oasis-open.org
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC