Should the CAS ticket be authoritative?
15 views
Skip to first unread message
Matt T
Sep 7, 2018, 9:54:07 AM9/7/18
to CAS Community
Hi Everyone,
I'll be the first to admin I'm no CAS expert. In fact, I don't even manage our deployments here. Instead, I work with applications which interface with it so I do understand to some degree. That being said, I have a question which came up in internal discussions I'm hoping to get some input on.
We have CAS delegating authentication to our IDP. Our IDP enforces two-factor auth so if we require it, we don't have to facilitate with CAS. We've run into an issue where every request to an application behind two-factor prompts the user for the second factor of authentication. This happens even when in a browser you've already verified. This is an issue because it takes away from the true SSO experience and a user can't move from app to app.
The main reason it is asking for the second factor again is due to the way we integrate CAS into our IDP. That's a whole different topic and really outside of the scope of this questions so just know we're aware of why it happens even if it isn't right.
The question is this. Is CAS ticket validity secure enough to trust only that? Why should we even check with our IDP a second time if the user's session already has a valid CAS ticket? Do others use this configuration or do you always check with the IDP?
It seems like trusting the CAS ticket if valid is the best option and would allow us to better control application logins and state but maybe I'm not thinking it all the way through.
Thanks in advance for any insight!
-Matt
I'll be the first to admin I'm no CAS expert. In fact, I don't even manage our deployments here. Instead, I work with applications which interface with it so I do understand to some degree. That being said, I have a question which came up in internal discussions I'm hoping to get some input on.
We have CAS delegating authentication to our IDP. Our IDP enforces two-factor auth so if we require it, we don't have to facilitate with CAS. We've run into an issue where every request to an application behind two-factor prompts the user for the second factor of authentication. This happens even when in a browser you've already verified. This is an issue because it takes away from the true SSO experience and a user can't move from app to app.
The main reason it is asking for the second factor again is due to the way we integrate CAS into our IDP. That's a whole different topic and really outside of the scope of this questions so just know we're aware of why it happens even if it isn't right.
The question is this. Is CAS ticket validity secure enough to trust only that? Why should we even check with our IDP a second time if the user's session already has a valid CAS ticket? Do others use this configuration or do you always check with the IDP?
It seems like trusting the CAS ticket if valid is the best option and would allow us to better control application logins and state but maybe I'm not thinking it all the way through.
Thanks in advance for any insight!
-Matt
Carl Waldbieser
Sep 7, 2018, 10:55:48 AM9/7/18
to cas-user
Matt,
It depends. If during CAS ticket validation, the validation result can assert that MFA took place for the authentication that created the TGT, then I think that would be sufficient if your requirement is simply that MFA took place already in the SSO session.
However, suppose not all services require MFA. If you first establish an SSO session to such a service, you might not be prompted for MFA. When you next go to a service that requires MFA, CAS would need to check in with the IdP so it could perform MFA, or else the SSO session would be denied access until it was terminated and a new SSO session was started that actually did use MFA.
If your setup is such that in order to establish an SSO session, you need to have provided a 2nd factor, then I would agree that CAS shouldn't need to check with the IdP each time whether MFA is valid-- the fact that the SSO session exists at all is based on the fact that MFA was successful. Whether it is possible to configure the software that way, I'm not sure.
Our own setup is the opposite of yours. We run both CAS and Shibboleth services. CAS clients interface directly with our CAS service. SAML2 clients interact with our Shibboleth IdP, but the IdP delegates all authentication to CAS so the SSO experience is unified. Our CAS service does need to signal to the IdP if MFA was used to establish the session. We require MFA on a per-user basis. Either a user will be required to use MFA to establish an SSO session or it will not. Any call to our IdP will always pass though to CAS to verify an SSO session exists. Users are only prompted for MFA once per session.
Thanks,
Carl Waldbieser
ITS Identity Management
Lafayette College
--
- 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/7ed4ac9e-139b-4273-b491-16ae953a9347%40apereo.org.
It depends. If during CAS ticket validation, the validation result can assert that MFA took place for the authentication that created the TGT, then I think that would be sufficient if your requirement is simply that MFA took place already in the SSO session.
However, suppose not all services require MFA. If you first establish an SSO session to such a service, you might not be prompted for MFA. When you next go to a service that requires MFA, CAS would need to check in with the IdP so it could perform MFA, or else the SSO session would be denied access until it was terminated and a new SSO session was started that actually did use MFA.
If your setup is such that in order to establish an SSO session, you need to have provided a 2nd factor, then I would agree that CAS shouldn't need to check with the IdP each time whether MFA is valid-- the fact that the SSO session exists at all is based on the fact that MFA was successful. Whether it is possible to configure the software that way, I'm not sure.
Our own setup is the opposite of yours. We run both CAS and Shibboleth services. CAS clients interface directly with our CAS service. SAML2 clients interact with our Shibboleth IdP, but the IdP delegates all authentication to CAS so the SSO experience is unified. Our CAS service does need to signal to the IdP if MFA was used to establish the session. We require MFA on a per-user basis. Either a user will be required to use MFA to establish an SSO session or it will not. Any call to our IdP will always pass though to CAS to verify an SSO session exists. Users are only prompted for MFA once per session.
Thanks,
Carl Waldbieser
ITS Identity Management
Lafayette College
- 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/7ed4ac9e-139b-4273-b491-16ae953a9347%40apereo.org.
Matt T
Sep 7, 2018, 11:47:43 AM9/7/18
to CAS Community
Carl,
This is very helpful. We actually run two CAS instances because of our IDP configuration. One (the one in question here) requires MFA while the other does not. So, if the CAS ticket in question is only valid in the MFA CAS instance, we can be certain the user has performed MFA. In that case, it seems like the CAS ticket is enough, right? Again, just checking my logic so sorry for redundant questions.
-Matt
This is very helpful. We actually run two CAS instances because of our IDP configuration. One (the one in question here) requires MFA while the other does not. So, if the CAS ticket in question is only valid in the MFA CAS instance, we can be certain the user has performed MFA. In that case, it seems like the CAS ticket is enough, right? Again, just checking my logic so sorry for redundant questions.
-Matt
Carl Waldbieser
Sep 7, 2018, 12:05:47 PM9/7/18
to cas-user
Matt,
Yes. I would say that if establishing a CAS web SSO session requires MFA, then one could infer that MFA had to have happened if ticket validation takes place successfully.
It might not leave you in the best position if you ever want to swap components around. E.g. if one day you decide to consolidate CAS services, suddenly all the clients that were not checking that MFA was asserted during ticket validation might need to be updated. That could be mitigated by forcing the MFA CAS service to assert that MFA took place during validation, and forcing clients to check that MFA was asserted. Again, I'm not sure how one would configure something like that in practice.
> email to cas-user+u...@apereo.org <javascript:>.
Yes. I would say that if establishing a CAS web SSO session requires MFA, then one could infer that MFA had to have happened if ticket validation takes place successfully.
It might not leave you in the best position if you ever want to swap components around. E.g. if one day you decide to consolidate CAS services, suddenly all the clients that were not checking that MFA was asserted during ticket validation might need to be updated. That could be mitigated by forcing the MFA CAS service to assert that MFA took place during validation, and forcing clients to check that MFA was asserted. Again, I'm not sure how one would configure something like that in practice.
> To view this discussion on the web visit
> https://groups.google.com/a/apereo.org/d/msgid/cas-user/7ed4ac9e-139b-4273-b491-16ae953a9347%40apereo.org.
>
>
--
- 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/eeebc1ec-8091-42a8-9b49-d726bc2efc3f%40apereo.org.
> https://groups.google.com/a/apereo.org/d/msgid/cas-user/7ed4ac9e-139b-4273-b491-16ae953a9347%40apereo.org.
>
>
--
- 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.
Matt T
Sep 7, 2018, 12:48:56 PM9/7/18
to CAS Community
I agree. We will discuss architecture but it's nice to confirm my logic. Again, thank you very much!
Ray Bon
Sep 7, 2018, 1:09:35 PM9/7/18
to cas-...@apereo.org
Matt,
I can confirm that log in to non MFA service and then MFA service requires a reissue of TGT. Are tickets shared between the two CAS servers? If not, then I could see multiple logins required as user is shuffled between servers.
At present I have only one MFA service to test against. But a valid TGT should be enough, otherwise the whole system would be pointless.
Ray
-- Ray Bon Programmer analyst Development Services, University Systems 2507218831 | CLE 019 | rb...@uvic.ca
Reply all
Reply to author
Forward
0 new messages