RE: [saml-dev] SubjectConfirmation in SAML query

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

> You can use ID-WSF
I read the overview. It talked about storing attributes at what are
effectively SPs and those SPs acting as proxy Attribute Authorities. So
you can end up with your personal profile all over the place.
It also seemed to rely on a user in it's scenarios. I couldn't see any
federated machine to machine, n-tier solutions. But I just had a quick
skim so maybe I missed something.

Bouncing attribute release decisions off the user in an n-tier hierarchy
would be pretty messy for the user. Federated search is a use case I have
just now. Each search service requires attributes, in the background,
without bothering the user. So they should all go and get their own
attributes, with SP1, the aggregating search SP, giving them enough
information to:

a) Find the IdP
b) Get attributes from the IdP by saying "you trust SP1 and here's the
proof it trusts me, so can I have this attribute?"

> That sounds needlessly complicated and violates any number of basic rules
> regarding the AuthnRequest protocol.
I haven't seen anything that addresses n-tier that isn't complicated. Come
to thik of it I haven't seen any, full stop!
If it abuses AuthnRequest then something is missing to support n-tier.
I'll keep snuffling.

> If you want it encrypted for SP2, you have no choice but to assume
> prior knowledge of SP2
yes

> It
> doesn't require a shared identifier for the principal between SP2 and the
> IdP if all you need are attributes
can you expand on that? what shared identifier are you talking about?

Alistair


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

>> 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.
>
> You can use ID-WSF. It's defined, you don't have to make it up. If you do,
> you'll end up with virtually the same specs anyway.
>
>> 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.
>
> That sounds needlessly complicated and violates any number of basic rules
> regarding the AuthnRequest protocol.
>
>> 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.
>
> Just have SP1 request a new token from the IdP to use at SP2, acting as
> the
> principal's proxy. That allows the user to permit (or not) SP1 to obtain
> the
> token. If you want it encrypted for SP2, you have no choice but to assume
> prior knowledge of SP2, at least to the extent of obtaining a key. It
> doesn't require a shared identifier for the principal between SP2 and the
> IdP if all you need are attributes. That's the usual prior knowledge most
> people worry about.
>
> -- Scott
>
>
>