CAS Interrupt Misunderstanding

[Shawn Cutting]

Good morning,

I am trying to create a dynamic interrupt page and I think I am misunderstanding what the "ssoEnabled" setting does.  From the documentation, it seems that if this is set to true, then it would give a service ticket despite the action that would be taken on the interrupt page.  Here is what I am trying to do:

I want to warn people that their passwords are about to expire (we use Active Directory as LDAP) and I am giving them the option to "Remind me in 3 days." This option updates a database with the reminder date and then should redirect to the service page they originally called.  But instead, it takes them back to the CAS login where they have to reauthenticate and it bypasses the interrupt per my code.  What I want it to do is, after pressing "Remind me" to take them to the service page without having to authenticate again, which is what I thought should happen with "ssoEnabled=true."

Can anyone give me some better insight?

Thanks!

[Tepe, Dirk]

We had a similar experience and I can share what we found. We have been on CAS 3.x for many years and used a customization to trigger similar web flow behavior. With the upgrade to CAS 5.x, we wanted to use the built-in functionality. Here is an exchange we had with a consultant related to the CAS project:

-----------------

Question:

> However, we can't seem to get ssoEnabled to work as expected. When ssoEnabled is true, we expect that the link to B presented in the message would not require the user to login again. However, that is not our experience. It seems CAS only builds the SSO session after the Proceed button is clicked, not when the links in the message are used.

Answer:

This is all correct and is the intended behavior. Given that CAS has never established SSO on the first run and B is protected by CAS, redirecting/accessing B will always ask for user credentials. One cannot build an SSO session first, only to then try to destroy it if SSO is interrupted. That would be a security breach in the right variations. You also can never make the link to B to work, because if a link to B appears in the interrupt screen, simply clicking it is not the same thing as CAS issuing a ticket to it after a successful authentication, for B to grab that ticket and validate it. The link is exactly that; just a link. You wouldn't have access to a ticket, because you have not properly passed through the SSO flow because you were interrupted. We have had situations in the past were tickets/sso were created prematurely before user were to access a link, (i.e. password self service app), and those cause many other weird issues.

The ssoEnabled flag basically controls whether CAS should challenge user for credentials and build the SSO cookie. It effectively should do the same thing as renew=true, and is more or less the same thing as ssoEnabled flag of a service in the registry. If this is dysfunctional, where you see REST return false for ssoEnabled and yet you are not challenged for credentials, that would be a bug we can try to fix. 

-----------------

The behavior we want would clearly create a security risk in the authentication process. (We recognized this in our 3.x mod as well, but accepted it at the time.)

We also provide a grace period for expired passwords. The act of checking for a login message triggers the password expiration and starts the grace period. If the person is still within the grace period, the message will not block and a Proceed button is presented by CAS. If the grace period has ended, the block is set to true and the Proceed button no longer appears. The message contains a link to the site where the user can change their password. This does not support SSO due to the nature of 'ssoEnabled' and the user must authenticate again. We present this a security feature. :)

The login interrupt messages are useful, but we have found that we must adapt our processes to the capability. I'm in favor of that because trying to maintain the modification to make CAS match our process is what kept us on 3.x for so long.

Hope this helps.

-dirk

--
- Website: https://apereo.github.io/cas
- Gitter Chatroom: https://gitter.im/apereo/cas
- List Guidelines: https://goo.gl/1VRrw7
- Contributions: https://goo.gl/mh7qDG
---
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 cas-user+u...@apereo.org.
To view this discussion on the web visit https://groups.google.com/a/apereo.org/d/msgid/cas-user/0c6e7901-7ef7-48b0-91d8-d2d5f10170d6%40apereo.org.

[Shawn Cutting]

Well, that is disappointing and reassuring at the same time.  Thankfully, I am just beginning the process of utilizing interrupts in this way, so I can easily shift my mindset for designing interrupts in the future.  Thank you for your quick feedback!!

Shawn

[Cutting, Shawn]

Well, that is disappointing and reassuring at the same time.  Thankfully, I am just beginning the process of utilizing interrupts in this way, so I can easily shift my mindset for designing interrupts in the future.  Thank you for your quick feedback!!

 

Shawn

 

You received this message because you are subscribed to a topic in the Google Groups "CAS Community" group.
To unsubscribe from this topic, visit https://groups.google.com/a/apereo.org/d/topic/cas-user/0zIKMbrV6po/unsubscribe.
To unsubscribe from this group and all its topics, send an email to cas-user+u...@apereo.org.
To view this discussion on the web visit https://groups.google.com/a/apereo.org/d/msgid/cas-user/CAJ%3D0EZzR_yjzQVKYCqaft3iLx2QYX5ofnGQunx_fH3n8vto2-A%40mail.gmail.com.