Shibboleth Developers

[Velpi <>]

[forwarded to Shibboleth-dev to continue the discussion there]

> I've never deployed Shibboleth (OIRT deploys Shibboleth at Rutgers as a 
> pilot) but from what Velpi has said it would seem that there are a large 
> number of institutions out there that deploy an integrated 
> CAS/Shibboleth package that it would make sense to ensure that we make 
> this as easy and painless as possible.  (I'm assuming its not as easy 
> and painless as it could be, but correct me if I am wrong there).

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.

> Out of the box CAS comes with a multitude of authentication handlers 
> that may be of use to the Shibboleth community (and eliminates a 
> duplicate work-effort).  The CAS server software itself is protocol 
> agnostic (we marshal our internal domain objects to the CAS protocol at 
> the last possible step) so we should be able to "communicate" with 
> Shibboleth in whatever form is required.

It would probably be better to move this question to shibboleth-dev and/or
engage with Chad, rather than me. I don't have much directly to do with this
aspect of the IdP design or development, and as a deployer I have only one
SSO system, Shibboleth itself, so it's largely invisible to me how the
requirements for handling authentication flexibility are met.

If Velpi and/or others want to have that discussion with Chad, we can also
certainly get on the phone and see what we think makes sense.

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.

-- Scott