Can a single SP front multiple disparate applications?

[Cantor, Scott]

On 9/6/13 2:50 PM, "Bryan E. Wooten" <bryan.wooten at utah.edu> wrote:
>
>While I agree with Scott philosophically about CAS (api Client
>integration) vs Shib the unfortunate reality is that CAS is much easier
>for in house developer's to implement  and results in less
>infrastructure/servers for my dept to maintain (ie many SPs).

As the others noted, usually that's not done centrally, though obviously
situations vary.

The fact is that actually getting an SP installed and configured when you
provide starter files usually is very simple. Where things are nasty is in
upgrades/maintenance, and largely because the older Windows SP absolutely
sucked on the installer side. Now that that's finally fixed, upgrades are
usually trivial (with one apparent exception, sorry Mike).

>Another reality is that we are resource thin and asking the developers of
>these 100s of applications to move off CAS and onto Shib would take years.

*That* of course is unsolveable (apart from the coexistence approach). But
it's the exact reason I fight to maintain the approach I use. Once you go
down the API path, you're in a much worse position. I was fortunate to
recognize this trap early on before we rolled out SSO here.

>The problem with the mod_auth_cas (mod_cas?) CAS client is that it does
>not support CAS attribute release which more and applications are
>requesting.

That's interesting. Perhaps somebody could fix it so that it does.

> Many of the attributes they desire are not part of eduPerson otherwise I
>would encourage them to use Shib. Though I suppose we could configure our
>IDP release custom attributes.

That is normal. Shibboleth doesn't care anything about eduPerson, those
are just defaults.

Curious to hear what those attributes they want are though, in my
experience there isn't much that isn't usually mappable to eduPerson or
other standard LDAP schemas that is commonly requested.

-- Scott