Shibboleth Developers

["Scott Cantor" <>]

> 2. The SP decrypts the identifier and maps it to a persistent, local
> identifier (account linking).

The SP doesn't map attributes, it just exposes them. Mapping could be a
function of an alternate attribute resolver, though.

> 3. The SP resolves local attributes and issues a local attribute
> assertion with bound SSO assertion (in <Advice>).

Having a resolver plugin do it would be possible, and resolvers can return
assertions to be added to the session cache (this is essentially what
happens when it makes a query, that plugin just adds that result to the
cache).

The big problem here is that this is simply a violation of the basic SSO
profile. The assertions you get cannot be passed to other relying parties
unless they're decorated in a fashion that permits that to happen.

> 4. SP exposes the local attribute assertion to the application.

Any assertions in the cache get mapped into local loopback URLs in headers
that can be resolved into the assertion.
 
> Questions:
> 
> * Can the Shib IdP 2.0 be made to issue such an assertion?
> * Will the Shib SP 2.0 do account linking?

The SP doesn't have accounts, so of course no. The SP is stateful only with
respect to sessions, it will never be stateful itself across them, though
various plugins can be.

> * Will the Shib SP 2.0 do local attribute resolution?

Interface yes, implementation no. The only resolver I wrote does SAML
queries (based on the subject of the SSO session).
 
> * If the answer to the previous question is no, will the Shib SP 2.0
> expose the raw SSO assertion?

If you dereference the loopback URL with the SAML URI binding, you get the
assertion. I believe by design the first URL it exposes is always the
original SSO assertion.

-- Scott