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

 


Help: OASIS Mailing Lists Help | MarkMail Help

saml-dev message

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


Subject: Re: [saml-dev] Confirming how holder-of-key profile works


Thank you very much Tom. Youve answered all the questions (or better
youve confirmed the ideas Id extracted).

I have only one question (or confirmation) more. Ive read in SAML
Core (3.3.2.3 Element <AttributeQuery>) that if there is no attributes
specified in the saml attribute query, the saml response issued by IdP
will contain "all attributes allowed by policy". Does it mean that in
the previous scenario (explained in the first mail) issuing a saml
request by the user with no attributes specified in it, we would
obtain a saml (holder-of-key assertion) response by the IdP, with ALL
the attributes associated to the subject (the user) in that IdP?

Thanks Luis M. Alvarez


2009/3/28, Tom Scavo <trscavo@gmail.com>:
> On Sat, Mar 28, 2009 at 4:20 PM, luismi alvarez santana
> <luismi.alvarez@gmail.com> wrote:
>> Hello everybody,
>>
>> Ive just read the SAM V2.0 Holder-ok-key Assertion Profile (CD 01, 9
>> March
>> 2009), and Id really appreciate a confirmation about what I think Ive
>> understood.
>
> I'm not really seeing any questions or comments in your message, but
> since this document is in its formal Public Review period right now,
> I've cc'd the security-services-comment list just in case.
>
>> The scenario Im interested in, implies an attesting entity (a
>> user) that tries to get some of their attributes from a SAML issuer (an
>> IdP)
>> in order to use them later in an access to a relying party (a SP). In
>> this
>> scenario, the steps would be:
>>
>> 1.- The user (acting as the attesting entity in the holder-of-key
>> profile)
>> build an attribute self-query saml assertion and send it to the IdP
>> (acting
>> as the SAML issuer)
>
> I think you mean a self-query SAML *request* but yes, that is one use
> case relevant to this profile.
>
>> 2.-IdP issues a holder-of-key assertion containing the attributes
>> requested.
>> In this assertion the subject element would refer to the users
>> identification used in the <saml:attributequery>, and the whole assertion
>> were bound to X509 data OF THE USERS CERTIFICATE (wasnt it?).
>
> If I'm understanding you correctly, you're suggesting that the IdP
> might bind a <ds:X509Certificate> element to the
> <saml:SubjectConfirmation> element, correct?  Yes, that is covered by
> this profile.
>
>> This implies
>> that IdP NEEDS to know the X509 certificate of the user.
>
> Yes, that's an important point.  Taking the relevant excerpt from the
> profile:
>
> "the SAML issuer MUST possess an X.509 certificate known to be
> associated with the attesting entity"
>
> This profile doesn't say how the SAML issuer comes to posses such a
> certificate, however.  That is left to higher-level profiles.
>
>> 3.- The holder-of-key assertion would act like an authenticating token,
>> when
>> would be presented to an SP (acting as the relying party), and the user
>> would prove the possession of the X509 certificate.
>
> Yes, by proving possession of the private key corresponding to the
> public key bound to the certificate.
>
>> In this step I then
>> understand three things: (a) SP doesnt need to know the X509 certificate
>> BEFORE the presentation of it by the user (on the contrary thet IdP, that
>> it
>> does)
>> (b) It isnt needed any other authentication process, because its more
>> than
>> enough the comparison of the X509 data contained in the assertion with
>> the
>> X509 presented by the client (and the associated private key)
>> (c) SP doesnt need to issue another <saml:attributequery> to the IdP (as
>> in
>> a normal access of a user with a token to an SP), because its able to
>> extract the attributes contained in the holder-ok-key assertion, and
>> process
>> them (for example with the intervention of a PDP, PEP entities)
>
> If I'm understanding you correctly, all of that is true, yes.
>
>> Could anyone help me to confirm if the exposed scenario would be
>> realistic?
>
> I think you've described the scenario quite accurately in fact.  Is
> there a question or comment in there that I missed?
>
>> Thank you very much in advance, and, please, sorry for the bad english
>> language I have.
>
> No problem.
>
> Tom Scavo
> NCSA
>


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