shibboleth using campus SSO for authn vs not

[Cantor, Scott]

On 8/26/14, 4:18 PM, "Liam Hoekenga" <liamr at umich.edu> wrote:
>
>I feel that if we were going to turn off Cosign, that it would make more
>sense to move our SSO infrastructure completely to shibboleth, rather
>than bringing up another SSO (CAS), get people to migrate to that while
>trying to spur shib adoption on campus.
>  If we're going to make them migrate, why wouldn't it be to the Shib SP?

You probably can make this case in the future even if you want to use CAS
clients. [1]

As far as the arguments, the pros/cons of my SP are pretty well known,
although it's not quite as much of a difference with cosign as it is with
CAS (from what I know, I'm not a cosign expert certainly).

FWIW, I would welcome help from people who know how to build native SSO
implementations and honestly it would be nice to see people not just
migrate from something but shift some of the resources into helping
maintain and enhance the thing they're moving to. I can't keep doing it
alone (meaning the SP).

>Institutional SSO + RemoteUser handler / UWLogin / MCB (RemoteUser)
>prevent having to migrate a campus from whatever SSO SP software you
>might be running to the Shib SP.  It lets you keep current campus based
>authn / authz stuff in place.  If it's a vendor solution, the vendor
>stuff keeps working.  I get that.

That too, but that's certainly why the CAS support Marvin's planning to
donate and maintain is a good thing.

>*Aside* from that stuff, is there a /real/ advantage to using another SSO
>to provide authn for the Shib IdP, rather than just using the Shib IdP to
>handle authn itself?

Well, the win is the flexibility of having different kinds of application
footprints and integration strategies, but that's why the protocols really
belong in the IdP code base (cosign included if UM is interested).

But certainly not isolating the question to the IdP, no. It's never as
simple that way as just using the system the way it was meant to be used.
The earliest history of the project has been a constant war between the
idea that we should defer authentication and those of us that believed we
needed to do it, and the results were always mixed because of a lack of
commitment. V3 is probably 90% about authentication and session management
redesign when it comes down to it. We're all in, finally.

I'm responsible for the majority of the code base over the life of the
project, and my view has always been that Shibboleth is an attribute-based
SSO first, and a federation solution second. That may be shocking if you
think it's a terrible enterprise SSO, but that's a reflection of differing
over requirements, not a lack of intent.

-- Scott

[1] http://marc.info/?t=140804144300012&r=1&w=2