>From what I understand of the CAS support in IdPv3, it only supports the >published standard for CAS v2, correct? Clients that rely on attribute release >will have to migrate to a SAML SP - how are you handling that? Were all of >your CAS clients authentication only or do you have to work with each service >provider to get them going with the Shibboleth SP? I like the idea of >decreasing the complexity in our deployment by just running Shib instead of >Shib+CAS, but if I have to increase the complexity on the service providers, >it doesn't seem worth the effort.
________________________________ Eric Pierce, CISSP Identity Management Architect | USF Information Technology [email protected] | Tel: (813) 974-8868 ________________________________________ From: [email protected] <[email protected]> on behalf of Kevin Foote <[email protected]> Sent: Tuesday, March 1, 2016 4:30 PM To: Paul B. Henson Cc: [email protected] Subject: Re: [cas-user] Migrating CAS clients to shib idp v3 cas service > On Feb 29, 2016, at 5:24 PM, Paul B. Henson <[email protected]> wrote: > > 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? Hi Paul, Same rough scenario here - only difference is the IdP has never relied on the CAS service for login (so very disjoint :). The one advantage this gives me is that the users of CAS clients have never expected the SSO scenario to work across our apps. :-) I agree in that collapsing the service URLs is basically crossing cookie domains which is really what you are up against. I opted to make the switch leaving both service URL’s in place. The CAS users have a given time frame to migrate their CAS URL logic to the new(er) location for the service via the IdP. In the mean time the actual protocol will be delivered by IdPv3, so If an app owner wants to take advantage of SSO then they can move at will to the new service location. -------- thanks kevin.foote -- 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/. -- 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/.
