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] SubjectConfirmation in SAML query

> 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

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