> 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/.
