On 1/11/13 7:45 PM, Andrew Morgan wrote: > On Wed, 9 Jan 2013, Andrew Petro wrote: > >> Hi Farzan, >> >> Shibboleth can be complex, yes, with much to learn about it and many >> opportunities to configure. >> >> The CAS-Shibboleth bridging piece isn't too bad. Here's my favorite >> solution: >> >> https://github.com/Unicon/shib-cas-authenticator >> >> I thought this presentation was pretty good: >> >> https://wiki.jasig.org/x/AxMoAw >> >> Hope that helps, >> >> Andrew > > I watched this presentation and read about the shib-cas-authenticator. > Neat stuff! >
I just got this running on a test environment as well. I appreciate the dev's (Dmitriy's) work to build this and put it on github. > > However, it appears that the CAS Client for Java in the IdP is keeping > the session "alive". Even if I logout of CAS, I am not redirected to > CAS for a new ST the next time use the IdP. I assume the CAS Client for > Java is storing my authenticated state in the Jsession. > The only shib SP I have tried from is testshib.org. After logging out of CAS, I went through the test page a second time and was not redirected to a CAS login page either. Would the CAS server need to do a single sign-out action with the shib-cas-auth facade to then log you out of Shibboleth? I'm really new to Shibboleth here, so it's pretty much out-of-the-box. I imagine Shibboleth is caching sessions in memory as well? I saw something on their wiki with regards to stateless clustering. I haven't gotten this far yet, but was wondering if it would be better if idp didn't cache. If I did that, would everything to go to the shib-cas-auth bridge? The other thing I trying to figure out.. Currently, we're running two CAS servers behind an Apache reverse proxy load balancer in production. I've got CAS, idP, and the shib-cas-auth bridge all running under one Tomcat instance on my dev box. I'd like to do the same thing in production. The Shib wiki indicated they recommend using Terracotta to replicate the state between clustered nodes. That sortof just adds yet another thing. If it's stateless and just relies on the cas bridge for everything, I'd be happy with that. I also don't know if the SP application needs to talk to the SOAP endpoint. If that is a requirement, then I think shib idp needs to keep a cache/state. That may be needed for passing attributes to the shib SP. Since the SOAP endpoint uses client certificates, the SP has to talk directly to Tomcat (no load balancing). Not needing SOAP, statefullness within idP or Terracotta would certainly keep it simple for me. This also brings up yet another question.. If we make attributes available to the shib-cas bridge, does that pass then on to shib idp? I have a feeling no, that I'll need to define attributes in idp and query DBs/LDAP from there. After working on the Shib idP some, I really appreciate the fact that CAS uses maven overlays and solely runs over http (no separate endpoints). These design decisions make it much easier to support. Pat -- You are currently subscribed to [email protected] as: [email protected] To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user
