replying to my own emails again!
Reading the profiles spec seems to suggest that SubjectConfirmation is a
means to "proxy" the "real" Subject?
i.e. if an asserting party says something about me then "I" am the Subject.
However, the asserting party can add additional information to the
assertion giving various third parties (attesting entities) the right to
"claim they are me"?
i.e. in bearer in web sso:
"The bearer of the assertion [The Browser] can confirm itself as the
subject [Me]"
in holder of key, the asserting party is basically saying:
"anyone who holds the key or certificate identified in the
SubjectConfirmationData can claim to be Subject" - subject to conditions
of course.
Does that mean that, say, SPa can sign something in the assertion ir got
from IdP before passing it on to SPb and SPb can use the certficate/key in
SubjectConfirmationData to verify that SPa indeed has the key identified
in SubjectConfirmationData? If so, then SPb can assume that the attesting
entity (SPa) has a relationship with the asserting party (IdP) via it's
key, which is identified in SubjectConfirmationData?
Alistair
--
Alistair Young
Senior Software Engineer
UHI@Sabhal Mòr Ostaig
Isle of Skye
Scotland
> Sorry to bring this up again but I was just beginning to understand it!
>
> I'll try and use a real world example.
>
> If an IdP issues an Assertion containing a Subject and Assertions about
> that Subject to SPa and also issues, say, an Assertion that has an
> AudienceRestriction for SPb. SPa holds the assertion destined for SPb.
>
> While the user identified by the Subject is doing things on SPa, they do
> something that causes SPa to communicate with SPb but not through the
> browser. It's machine to machine. SPb wants an assertion about the user to
> verify they have access to SPb. SPa gives the AudienceRestriction'd
> assertion to SPb.
>
> Now, I believe, this is where SubjectConfirmation comes in? SPb can use
> this to work out the relationship between SPa and the Subject?
>
> In the example in the SAML Core spec, the Subject and KeyInfo in
> SubjectConfirmationData "belong" to the user.
>
> My reading of this seems to be:
>
> "Here's the subject and if you want to confirm them (whatever that means),
> here's their key too"
>
> but SubjectConfirmation is for SPb to identify the relationship between
> SPa and the Subject:
>
> "The <SubjectConfirmation> element provides the means for a relying party
> [SPb] to verify the correspondence of the subject of the assertion
> [Scott@xxxxxxxxxxx] with the party with whom the relying party is
> communicating [SPa]".
>
> What is SPb meant to do with the key from the KeyInfo?
>
> Am I really missing something?
>
> thanks,
>
> Alistair
>
>
>
>
> --
> Alistair Young
> Senior Software Engineer
> UHI@Sabhal Mòr Ostaig
> Isle of Skye
> Scotland
>
>>
>>
>>
>>
>>
>>
>>
>>
>> Giuseppe Sarno wrote on 11/10/2005, 8:35 AM:
>>
>>
>>
>>
>> AP
>> could include a HolderKey confirmation method + key.
>>
>> This
>> means that the Party A should prove somehow that he holds that key (by
>> enc/decryp a message or the NameID itself or by any other mean) with
>> the RP.
>>
>> (this
>> where it gets a little bit confuse, how the PartyA proves he holds the
>> key)
>>
>> I
>> guess though this must be out of the scope of SAML. (if you have an
>> example it would be helpful)
>>
>> The best example
>> would be the proposed SAML token profile v1.1 for WSS (available at:
>> http://www.oasis-open.org/committees/download.php/15256/Web%20Services%20Security%20SAML%20Token%20Profile-11.pdf)
>>
>>
>>
>> For
>> the Subject in the Confirmation, sorry I didn't mean subject but
>> BaseID/NameID/Enc...ID instead. They are present at the Subject level
>> as well as the SubjectConfirmation level.
>>
>> In the Subject
>> Confirmation, this is the identity of the *entity* that is able to do
>> the confirmation, if available. In your example, Party A would be the
>> entity sending the message to RPA and would be identified with an ID in
>> the subject confirmation. Of course, if Party A was a browser, it
>> doesn't have a unique identity and so there would be no identity there
>> in such a case.
>>
>>
>>
>> But
>> looking at the schema I assume that those will be included in the
>> confirmation only if they are not present at the Subject level.
>>
>> That's not the
>> case. They ID's identify different parties (the Subject vs the entity
>> that can meet the confirmation requirements).
>>
>> In our model, the SubjectConfirmation IDs (SCIDs) would not be present
>> during browser based SSO or with tokens issued to intelligent clients
>> (active participants in the SSO process), when either client
>> communicates with a relying party. But later, when that relying part
>> turns around and invokes another service that is part of the same
>> "session" with the Subject, the token that they get to invoke the
>> subsequent service will include the identiy of the relying party in the
>> SCID). So we will have tokens with or without SCIDs depending upon the
>> context.
>>
>> Conor
>>
>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> This publicly archived list supports open discussion on implementing the
>> SAML OASIS Standard. To minimize spam in the
>> archives, you must subscribe before posting.
>>
>> [Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/
>> Alternately, using email: list-[un]subscribe@xxxxxxxxxxxxxxxxxxxx
>> List archives: http://lists.oasis-open.org/archives/saml-dev/
>> Committee homepage: http://www.oasis-open.org/committees/security/
>> List Guidelines: http://www.oasis-open.org/maillists/guidelines.php
>> Join OASIS: http://www.oasis-open.org/join/
>>
>>
>
>
> ---------------------------------------------------------------------
> This publicly archived list supports open discussion on implementing the
> SAML OASIS Standard. To minimize spam in the
> archives, you must subscribe before posting.
>
> [Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/
> Alternately, using email: list-[un]subscribe@xxxxxxxxxxxxxxxxxxxx
> List archives: http://lists.oasis-open.org/archives/saml-dev/
> Committee homepage: http://www.oasis-open.org/committees/security/
> List Guidelines: http://www.oasis-open.org/maillists/guidelines.php
> Join OASIS: http://www.oasis-open.org/join/
>
>
|