Shibboleth Developers

["Scott Cantor" <>]

> > I don't think our implementation should be creating a
> > proprietary SSO scheme within the standard one. 
> 
> I don't believe I proposed anything that goes against the
> SAML1-Shibboleth specs.  The SSO profiles are *exactly* the same as
> before.

I didn't say it violated the spec, I said it layers a proprietary SSO system
behind the standard one. Which it does.

SSO can be defined as transiting a cookie-based session with one vhost to a
cookie-based session with a second vhost. This is perhaps overly specific,
but it is mostly accurate. It doesn't matter whether those vhosts are one
process, one box, one network, or the Internet, except that different
protocols can be used in different cases because of shared memory or data.

Any SSO scheme that works between boxes can be used in any of those
scenarios and can replace SAML because it does the same thing. The
difference is in the details (and the willingness of both ends to deploy
it).

> The issue is one of implementation (finally! :) and I claim
> separating the RM from the SP leads to more flexible implementations,
> not the other way 'round.

Of course it does. Any time you offer two different technical solutions to
solve the same problem, you add flexibility. You also decrease
standardization. It's a trade-off, I just happen to come down on a different
side of it.

But I'm also not seeking to prevent you (or Howard or anybody else) from
doing it. I simply want to preserve my ability to deploy SAML (using this
code) end to end for actual applications, and to distinguish the two
approaches because one is using SAML for SSO and one is a SAML gateway to a
non-SAML SSO system. (There are also policy implications involved in
claiming an SP is one "thing" when in reality it's gatewaying users to many
different things, which is what I was really speaking to in my earlier
notes.)

What you're proposing is possible now. It's also more work that somebody has
to do to propose, vet, and document a new SSO protocol (and a functional
translation between it and SAML. Requests, for example, have to be mapped
across the two, so that your non-SAML SP can issue requests that the SAML
gateway can turn into a SAML (or for now, Shib) request.

-- Scott