Shibboleth Developers

["Scott Cantor" <>]

> This is my original design, but Scott believes in a "one SP per
> application" view for real security. You can deploy my code either way.

It's not a question of security, but transparency. Obviously it can be 
secure, there are a hundred Web SSO protocols in the world,
and this is really just a subset that you're talking about, where the flow is:

- exchange session ID between local and remote entity
- attach session data to key at remote entity
- invoke secure callback to remote entity to look up/cache data for session 
at local entity

In fact, my old system does exactly that. It's secure. It's just not 
necessarily SAML, and none of the local entities would be
visible to a SAML IdP that issued assertions to the SAML SP tha's playing the 
part of remote entity in that equation (unless I
created enough translation to make them visible).

I'm only objecting on the grounds that:

- making it secure across machines isn't trivial, you still have to implement 
something there (shared key, whatever) and you have to
document what that is because it's a new protocol, provide more security 
configuration, etc.

- doing it right requires the transparency that's missing in an opaque 
gateway, or the SP becomes such a large aggregation that
ARPs/etc. becomes muddled, which isn't hard but is additional work.

I have *no* problem with a design that supports it. It's more or less what I 
was hoping to do to the cache interface in the C++
version, basically turn it into a more complete service abstraction that 
would be local-RPC remoted based on the current code. We'll
look what what you've got, frankly, no reason to start from scratch.

-- Scott