Thank you very much Tom. You扉e answered all the questions (or better
you扉e confirmed the ideas I悲 extracted).
I have only one question (or confirmation) more. I扉e 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 <>:
> On Sat, Mar 28, 2009 at 4:20 PM, luismi alvarez santana
> <> wrote:
>> Hello everybody,
>>
>> I扉e just read the SAM V2.0 Holder-ok-key Assertion Profile (CD 01, 9
>> March
>> 2009), and I悲 really appreciate a confirmation about what I think I扉e
>> 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 I惴 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 USER巽 CERTIFICATE (wasn愒 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 doesn愒 need to know the X509 certificate
>> BEFORE the presentation of it by the user (on the contrary thet IdP, that
>> it
>> does)
>> (b) It isn愒 needed any other authentication process, because it愀 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 doesn愒 need to issue another <saml:attributequery> to the IdP (as
>> in
>> a normal access of a user with a token to an SP), because it愀 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
>
