Migrating CAS clients to shib idp v3 cas service

[Marvin Addison]

On Mon, Feb 29, 2016 at 8:23 PM Paul B. Henson <henson at cpp.edu> wrote:

> For an external redirect, I would point auth.cpp.edu at a system that
> would redirect any attempted access to https://auth.cpp.edu/cas/ to
> https://idp.cpp.edu/idp/profile/cas/. What would CAS clients do in the
> face of such a redirect though? Would they follow it and function? Would
> they break? Would some work but others not?
>

The /login URI is mediated by the browser, so redirects will be no problem
there. The behavior on the /serviceValidate and /samlValidate, on the other
hand, are back channel calls from the client code directly to the CAS
server. Those are the ones that you'd have to test on a case-by-case basis.
I am fairly certain the Java CAS client will work fine since it uses
HttpURLConnection, which follows redirects by default [1]. I don't about
the others offhand.


> Any other suggestions on how to transparently accomplish this migration
> while maintaining single sign-on during the cutover?
>

If the external redirect doesn't work for your set of clients, I'd focus on
explaining to your management that you can't do the impossible. FWIW, we
did what you proposed initially: stood up a new IdP that supported both and
migrated services at their convenience to the new system. I think it's fair
to say it went smoothly for everyone: users, sysadmins, and managers.

M

[1]
https://docs.oracle.com/javase/7/docs/api/java/net/HttpURLConnection.html#setFollowRedirects(boolean)
<users-unsubscribe at shibboleth.net>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/users/attachments/20160301/c95e78cd/attachment-0001.html>