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

[Tom Scavo <trscavo@gmail.com>]

On Sun, Mar 29, 2009 at 6:26 AM, luismi alvarez santana
<luismi.alvarez@gmail.com> wrote:
> Thank you very much Tom. You´ve answered all the questions (or better
> you´ve confirmed the ideas I´d extracted).
>
> I have only one question (or confirmation) more. I´ve 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?

Well, first I'll note this question has nothing to do with
holder-of-key subject confirmation since the same is true regardless
of the requester.  The spec says it all: "all attributes allowed by
policy."  There's no point trying to rephrase it for clarity since
that is as precise as it gets.  If the IdP's policy is to return ALL
attributes to a self-requester, then that's what you'll get.  I rather
doubt an IdP would have such a policy but that's besides the point.

Unless you (the requester) knows the IdP's policy with respect to
attribute release, it's almost always better to ask for specific
attributes in the request.

> Thanks Luis M. Alvarez

Hope that helps,
Tom

> 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,
>>>
>>> I´ve just read the SAM V2.0 Holder-ok-key Assertion Profile (CD 01, 9
>>> March
>>> 2009), and I´d really appreciate a confirmation about what I think I´ve
>>> 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´m 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´S CERTIFICATE (wasn´t 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´t 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´t needed any other authentication process, because it´s 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´t 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´s 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
>>
>