No, I don't want to prompt the user at each auth attempt. Once they have authenticated with CAS I only want the IDP to get a new ST at each auth, which is what is not happening. I want the IDP to depend on CAS to determine if there is an active SSO session. So, I want a new ST at each auth even though most often the TGT cookie will result in just a new ST generated.
The essence of what we want is one point of controlling SSO session time. I don't want to manage session timeout in CAS and the IDP and various SPs, etc. Since CAS should be the controlling element I want everything as much as possible to refer to CAS as often as possible. I think the key here - pointed out by Tom - is that the CAS client is maintaining a session similar to an SP. I've tried tuning the Tomcat session timeout for my IDP in order to reduce that and I'll see what the effect is. Thanks. Ted F. Fisher Information Technology Services -----Original Message----- From: Marvin Addison [mailto:marvin.addi...@gmail.com] Sent: Thursday, August 07, 2014 2:37 PM To: cas-user@lists.jasig.org Subject: Re: [cas-user] CAS integration with Shibboleth IDP > We have our Shibboleth IDP using CAS as the only login handler resulting in > CAS being the manager of the SSO session and Shibboleth being simply a > pasthrough for SAML. Since the Shibboleth IDP does not maintain an SSO > session it should redirect to CAS for each auth request to get a new Service > Ticket. While your expectation is correct, I have the feeling you want to prompt the user for credentials on every federated service access request. Unfortunately that is not possible. If you disable the Shib "Previous Session" authn handler [1], which is the meaning I take from "Shibboleth IDP does not maintain an SSO session", you will still incur exactly one CAS authentication. The reason is that for any browser-mediated SAML profile, browser cookies come into play. Here's the flow: 1. User browses to spA.example.org 2. User selects home institution and is redirected to idp.bar.edu 3. IdP engages CAS authentication provider, which triggers redirect to CAS, cas.bar.edu 4. No CASTGC cookie is present, so user is prompted to login to CAS 5. User authenticates to CAS and is redirected to idp.bar.edu with ticket 6. IdP validates ticket and authn engine completes successfully 7. IdP redirects to spA.example.org with SAML response 8. ... time passes ... 9. User browses to spB.example.org 10. IdP engages CAS authentication provider, which triggers redirect to CAS, cas.bar.edu 10. CASTGC cookie is present so CAS issues ticket to IdP via redirect 11. Steps 6-7 as before So while a new ST is granted for every federated service access request, only one login occurs, the one that initiated the CAS SSO session. Thus you will see exactly one CAS login for a number of federated service access requests that happens during the lifetime of the CAS SSO session. While the renew CAS protocol parameter could theoretically help you here, the SP would have to set that flag, which is outside of your control. I hope that explains the behavior you are seeing. [1] https://wiki.shibboleth.net/confluence/display/SHIB2/IdPAuthPreviousSession M -- You are currently subscribed to cas-user@lists.jasig.org as: tffi...@bgsu.edu To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user -- You are currently subscribed to cas-user@lists.jasig.org as: arch...@mail-archive.com To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user
