We currently run the shibboleth idp v2 and cas server v3.5, with the idp authentication delegated to cas. We are working on upgrading to idp v3, and tentatively planning to migrate to the cas protocol support in the idp software. I was originally planning to separate cas and shibboleth authentication during the migration, with our shibboleth services authenticating against the new idp v3, and our cas services authenticating against our existing cas servers, and then migrate cas services to the new idp v3 one at a time. However, management has decided it is not acceptable to segregate our existing sso into two pieces and I need to find a way to maintain single sign-on across both our cas and shibboleth services during the migration.
On the idp side, it's pretty easy, just update our load balancer to point to the new idp instances. For cas, it's a bit more complicated. Our idp is located at idp.cpp.edu, and our cas servers at auth.cpp.edu. Initially it seems there are two ways to transparently migrate the cas clients, either with an external redirect, or an internal rewrite. 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? For the internal rewrite, I would point auth.cpp.edu at the system running idp.cpp.edu, and use the tomcat 8 rewrite valve to internally translate access to /cas / to /idp/profile/cas/. This would be transparent from the point of view of the CAS client. However, from the perspective of the client browser, CAS services would be accessed via auth.cpp.edu, and shibboleth services via idp.cpp.edu, which presumably would result in different session cookies, and mismatched SSO, and the lack of single sign-on between CAS and shibboleth applications that was the requirement to begin with? Any other suggestions on how to transparently accomplish this migration while maintaining single sign-on during the cutover? Thanks... -- Paul B. Henson | (909) 979-6361 | http://www.cpp.edu/~henson/ Operating Systems and Network Analyst | [email protected] California State Polytechnic University | Pomona CA 91768 -- You received this message because you are subscribed to the Google Groups "CAS Community" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. Visit this group at https://groups.google.com/a/apereo.org/group/cas-user/.
