Shibboleth Developers

["Alistair Young" <>]

> It doesn't pass the Subject, it just attaches assertions. If they have a
> subject usable by SPb for queries, that's fine.
ok, so SPa could get encrypted attribute assertions from the IdP and pass
them on to SPb via SAML Token Profile. If those attributes are enough to
grant the user access to SPb then fine, otherwise SPb must use the Subject
of the assertions, together with SecurityTokenReference to contact the IdP
and get more attributes.

The loopback would be unlikely if SPa already has the full set of
attributes (encrypted) that SPb requires and they come through on
WS-Security SAML Token Profile.

It just seems more wire efficient passing a Subject and letting SPb do
it's own attribute work. At the end of the day SPa doesn't care what SPb
needs and if SPb gets it's own attributes they don't need to be encrypted.

> It wouldn't necessarily extract anything. Just signs the token into the
> message. Most people don't want their apps to have to go plowing through
> assertions to use them as security tokens.
I'm not sure I understand what you mean by "signs the token into the
message". There doesn't seem to be much use in a delegation assertion that
doesn't have attributes as in most cases SPb will require extra attributes
over and above what SPa gets. Of course, SPa can never forward SPa
specific attributes to SPb as it would probably be breaking the IdP's ARP.

>> SAML Token Profile still has AuthorityBinding in it (it seems).
>
> For SAML 1.1 assertions.
So is there no way for SPa to communicate to SPb the home location of the
Subject of the Assertions? Or will SPb know it from it's metadata?

It seems the constrained delegation breaks down when SPa doesn't know the
full chain of delegation awaiting it. i.e. it does a search at SPb using
constrained delegation and that causes SPb to search SPc. The IdP knows
about SPc but SPa doesn't so it can't request delegation for it from the
IdP. Instead SPc could go straight to the IdP with the Subject and get the
atttibute assertions directly. Cross federation searching? If the Subject
can cross out of the fed then the loopback profile would cater for cross
fed service access. N-Tier problem? In effect, you're passing a SAML
"agent" among web services. An "agent" that has an ID that it's "owner"
IdP knows about and also contains the "agent" also has the location of
it's "owner".

As the "agent" hops from service to service via the SAML Token Profile,
the loopback addresses the N-Tier problem. Or have I misunderstood what's
meant by N-Tier? (probably)

Alistair


-- 
Alistair Young
Senior Software Engineer
UHI@Sabhal
 Mòr Ostaig
Isle of Skye
Scotland

>> I see clearer now, thanks to you both. I understand Scott's idea of SPa
>> asking the IdP to release encrypted attributes for SPb. So potentially
>> SPa
>> could be extracting n sets of encrypted attributes for the SPb...n that
>> it
>> knows it may talk to.
>
> It wouldn't necessarily extract anything. Just signs the token into the
> message. Most people don't want their apps to have to go plowing through
> assertions to use them as security tokens.
>
>> That could be a lot of attributes that may not be needed and could
>> expire
>> depending on an IdP's SP policy but it allows SPa to forward the
>> encrypted
>> attributes to SPb, SPc, SPn when those SPs are invoked. In this case,
>> SPb
>> - SPn are web services and not traditional shibb SPs, so we're using the
>> WS-Security SAML Token Profile 1.1 (which I found!).
>
> Right. But that profile isn't just a single profile, it provides a
> completely general attachment model. You can't get interop with that
> alone.
>
>> The alternative is SPa only gets it's own attributes and when contacting
>> SPb, passes on the SAML Subject and SPb uses this to get attributes for
>> that Subject specific to SPb. A SAML loopback profile if you like. SPb
>> loops back to the IdP with the Subject it got from SPa.
>
> It doesn't pass the Subject, it just attaches assertions. If they have a
> subject usable by SPb for queries, that's fine.
>
>> SAML Token Profile still has AuthorityBinding in it (it seems).
>
> For SAML 1.1 assertions.
>
> -- Scott
>
>