shibboleth using campus SSO for authn vs not

[Liam Hoekenga]

Our IdP uses our campus SSO (+ the UWLogin login handler) to handle authn.
We need to deploy a new rev of the SSO (Cosign).

One of my managers has suggested that rather then spending a lot of time
improving our Cosign infrastructure, why not consider moving to CAS?
Presumably then, our IdP would use CAS for authn.

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?

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.

*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?

Liam

[Cantor, Scott]

Post by Liam Hoekenga
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).

Post by Liam Hoekenga
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.

Post by Liam Hoekenga
*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