Shibboleth Developers

["Scott Cantor" <>]

> So let me see if I understand this.  A portal is protected by an SP,
> so the portal knows the user's preferred IdP.

A portal using this is usually thought of as being part of the IdP's domain,
but discovery really has nothing to do with this extension, that's always
out of scope.

> Instead of exposing
> links to other 3rd-party SP-protected resources (which would require
> IdP discovery), the portal handles all AuthnRequests itself, using the
> extension mechanism to target the response to the 3rd-party SP.
> Correct?

A portal is one use case, but the extension has nothing to do with
discovery. If I ask for the IdP, I still have to send a request. If I'm not
the SP, I can't sign it today without this extension.

The point is that if an IdP is requiring signed requests, then you either
have to play games inside your implementation to bypass the signature check,
or you need a way to signal that the signer != issuer, or you need a way to
separate issuer from the relying party.

Normally the issuer is the relying party, it's implied. This is just one way
to break the equivalence. The other is potentially to signal it in an
Audience in the request, but that would have changed the profile.

-- Scott