If you are going to use CAS to handle the authentication for the Shib IdP, then you almost certainly want to rely on CAS to maintain the session with the user. So you want to remove/"comment out" the PreviousSession handler for the Shib IdpP, and you might also want to reduce the session lifetime setting (how long the IdP would maintain session info for the user, whether or not you use the PreviousSession handler) in the config file IDP_HOME/conf/internal.xml:
from: https://wiki.shibboleth.net/confluence/display/SHIB2/IdPUserAuthn "The session lifetime is configured in the IDP_HOME/conf/internal.xml file. Locate the shibboleth.SessionManager bean. Its second constructor argument is the inactivity timeout, in milliseconds, for the session. By default it is 30 minutes." You may also want to read: https://wiki.shibboleth.net/confluence/display/SHIB2/IdPAuthnSession This all gets pretty complex. And you *cannot* pass attributes from CAS to the Shib IdP in any easy way. To do something like that, you have to run an IdP proxy with a SAML SP in front of it, and if you want that architecture, you'd likely want to look at something other than Shib (like SimpleSAMLphp). The Shib IdP is written to very flexibly retrieve attributes from attribute stores (directories, databases) and pass them on, and will be a whole lot easier to work with if you use it that way. There is no simple answer to your clustering questions. Other than stay away from Terracotta if at all possible. Very few sites actually have use cases that require getting into stateful clustering and Terracotta. If you don't need to support SAMLv1.1 (e.g. Shib v1.x) SPs, and with CAS underneath Shib handling the actual authentication/SSO sessions, you likely could run multiple IdP instances without any kind of clustering. The only time you usually need to support the back-channel SOAP connection from an SP is when you are dealing with a Shib SP v1.x that only supports SAMLv1.1 (versus SAMLv2). If you need to support the latter, then use stateless clustering as per: https://wiki.shibboleth.net/confluence/display/SHIB2/IdPStatelessClustering On Jan 13, 2013, at 3:44 PM, Patrick Hennessy wrote: > 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 -- Michael A. Grady Senior IAM Consultant, Unicon, Inc. -- 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
