Shibboleth Developers

[Velpi <>]

> Well, I think it's mostly painless until you want logout or proper handling
> of SAML 2.0, but I could be misled. Since Shibboleth today is neither
> logout-aware or very sophisticated wrt SSO requests, I don't think it's all
> that hard to use them together right now.

You're right. It's not very hard at the moment... unless you want to add 
things like (single) logout, non-SSO logins, LOA-based authZ etc. And 
that's what we're all heading for.


> Ultimately I think it's the usual question of the cost/benefit of 
> sharing or
> forking a body of code vs. implementing something directly. I could only
> speculate that the bulk of that code will be the same, but that the real 
> win
> here that Velpi is after is not really the authentication code but actual
> support of the CAS protocol such that the IdP session itself is shared.
>
> But it may be that the need for us to support logout and the knowledge that
> people *will* want to use other SSO systems with the IdP mean that the
> session integration we have to support will make what Velpi is doing now
> much easier regardless, even without native addition of the protocol.

Yes, it would be a great win (for logout) if the session/state itself 
could be shared. However the biggest issue with authentication handlers 
is that it is a highly *specific* need for every deployer (a combination 
of X.509, username/pass, digipass, SPNEGO/kerberos, RADIUS, LDAP, 
SQL...). CAS is popular (in Europe) because it makes integration easy 
and flexible. Integration with existing systems will always be a key 
issue. That's the main idea that I would to keep alive while all of us 
are very busy making the magic happen ;).


-- Velpi