CAS Integration Module for Shibboleth IdP

[Cantor, Scott]

On 3/6/13 2:41 PM, "Marvin Addison" <marvin.addison at gmail.com> wrote:

>I am planning an R&D project on a CAS integration module for the Shib
>IdPv2 sufficient to allow existing CAS clients to leverage the IdP as
>a CAS server. A putative CAS-enabled IdP would allow us to consolidate
>federated SSO (Shib) and institutional SSO (CAS) into a single product
>to reduce engineering and support costs for our institution. I can
>imagine this work would be of interest to other institutions that
>deploy and support both CAS and Shib.

It's certainly never been a goal of the project to not do it, but none of
the core team have generally been CAS-knowledgeable.

The main problem is the layering in of non-XML protocols into v2, which I
think mainly manifested in the attribute layer. But if you're using SAML
1.1 for that, that's already built-in and will probably make it rather
simple to do.

>A cursory review of IdPv2 source suggests that I could leverage
>ProfileHandlers to examine requests for signs of CAS protocol
>behavior; either via URI or request parameters (though the IdP appears
>to assume URI-driven behavior by default).

It's definitely been a core design choice to avoid overloading endpoints
in either the IdP or SP. This is mainly, in SAML, because we wanted to
abstract the message decoding and so we have to know which decoder to run,
without leaking binding details into the surrounding code.

>If the proof of concept is promising, I am interested in collaborating
>more
>closely to contribute this module into the IdPv3 as a bundled module
>or blessed third-party extension.

I hope very much that we can make that happen.

Notwithstanding Tom's question, I think you'll find that the worst part of
the IdP is the login handler handoff and return, and the session code, and
I'm sufficiently familiar with that to answer questions as they arise.

-- Scott