Shibboleth Developers

["Scott Cantor" <>]

> 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