Shibboleth Developers

["Scott Cantor" <>]

> There are obvious advantages and disadvantages to this approach.  It
> is efficient in one sense because there is only one execution of a
> Shibboleth SSO profile per browser session per user.  At the same
> time, it is somewhat inefficient since each application makes an
> (intra-domain) HTTP request to the SP to retrieve the security
> context.  It seems like a reasonable trade-off though.

Is it necessary for our implementation to be a proxy/gateway? If somebody
wants to build that, they can do it using our implementation and it can work
exactly as you propose (with maybe some small additions). I would treat it
as an extension of the existing work, not as the primary means of
deployment. I think proxies complicate things, not simplify them.

> In terms of maintenance and other technical requirements, one SP is
> clearly preferred to multiple SPs scattered throughout the security
> domain.  Of course multiple SPs are still possible if the situation
> warrants.

I disagree. An SP represents a service, not an organization.

> This architecture also solves a nagging problem, that is, local SSO. 
> A security domain simply deploys both an IdP and an SP (of the kind
> described above) to achieve global SSO.  In the eyes of such a
> Shibboleth SP, a local user and a remote user go through the same
> sequence of steps.

The existing implementation can already address local SSO and already
unifies access. I'm using it for that right now. If somebody wants a lighter
footprint SP, they can replace parts of our implementation with simpler
versions, but I don't think our implementation should be creating a
proprietary SSO scheme within the standard one. And that's what you're doing
if you cross-walk hosts.

I realize that's what the vendors do, I just don't happen to agree with it.
For all the attention SAML's supposed security holes gets, you'd think
somebody might notice all the unvetted protocols those products use behind
the scenes.

> I'm sure this has been considered before but I didn't find anything
> along these lines in the archives so I thought I'd bring it up now. 

It's quite well understood (by me at least). It's a way of doing SAML "a
little" but not doing SAML end to end. I believe it's a degenerate case of
what our implementation needs to allow for, not the primary vehicle for
deployment.

-- Scott