Re: [saml-dev] SubjectConfirmation in SAML query

["Alistair Young" <alistair@smo.uhi.ac.uk>]

> a principal
> wielding an AuthnRequest could ask for multiple SubjectConfirmation
> elements, one with method 'bearer' to present the assertion to SP1 and
> another with method 'holder-of-key' so that SP1 could forward the
> assertion to SP2
yes I've seen that before. Constrained delegation I think? The principal
has to get all the attributes up front and must know which SP needs which
ones. The IdP also has to know about all the SPs that could be involved.

In reality the principal and IdP won't know. The use case I have is a
principal gains access to SP1. SP1 is an aggregator of some sort, let's
say an RSS aggregator. It pulls feeds from other SPs. All SPs require an
attribute from the principal but they all require a different one.

The question is how to get the other SPs to "act as principals". i.e. the
original principal delegates to SP2 ... SPn and they go off to the IdP to
get their own attributes.

SP2 would reply to SP1, "I need attributes for this call". SP1 says, "ok,
here's what I have on the user". SP2 did what SP1 did to get attributes
but SP1 has signed the AuthnRequest it gives to SP2 and marks the response
to be sent to SP2 and only SP2. So SP1 doesn't see attributes it
shouldn't.

The crux is, the IdP may never have seen SP2 before. So how does it trust
it and work it's ARP accordingly? That's the bit I'm working on.

Alistair


-- 
mov eax,1
mov ebx,0
int 80h

> On 2/11/07, Alistair Young <alistair@smo.uhi.ac.uk> wrote:
>> ok, thanks. So the SP is "client authenticating" the "user" and using
>> information in the X509 of the user to get their attributes.
>>
>> The IdP takes no part in the authentication of the user.
>>
>> Presumably the location of the IdP can be inferred from the contents of
>> the X509.
>
> That's the crux of attribute query (section 3), yes, but I was
> referring to section 4 (self-query).  In that case, the principal
> queries the IdP directly and pushes the resulting attributes to an SP.
>
>> This looks interesting for machine to machine as well and passing tokens
>> between SPs when using web services (sorry!). If an aggregating SP
>> passes
>> the extended AuthnRequest it constructs to other services it has a
>> relationship with, those other services can use that AuthnRequest to get
>> their own attributes.
>
> I'm not sure why an SP would pass an AuthnRequest to another SP.
> Anyway, here's what I had in mind:
>
> 1. The principal issues an extended AuthnRequest (with attributes) to the
> IdP.
> 2. The IdP returns a signed assertion to the principal.  The assertion
> contains an AuthnStatement and an AttributeStatement.
> 3. The principal presents the assertion to an SP.
> 4. The SP makes an access control decision and does the right thing.
>
>> The interesting question for me is how to authenticate those other
>> services at the IdP. If the IdP trusts SP1 then perhaps it could trust
>> those SPs that SP1 trusts. SP1 signing an AuthnRequest and setting the
>> AssertionConsumerServiceURL to SP2's service would be interesting for
>> n-tier machine to machine.
>
> This is slightly off topic, but I will mention that a principal
> wielding an AuthnRequest could ask for multiple SubjectConfirmation
> elements, one with method 'bearer' to present the assertion to SP1 and
> another with method 'holder-of-key' so that SP1 could forward the
> assertion to SP2.  Scott suggested this basic approach some time ago,
> I believe.
>
> Tom
>