I think we might have figured out what causes this (have not been able to
answer the why yet).
This issue can be reproduced with both 6.4.0-RC5 and 6.4.0-RC6, 6.3.6
versions (and maybe other versions as well).
Here is our scenario, we have 2 services configured with CAS.
Service A (RegexRegisteredService): Uses Username, Password and MFA
(GoogleAuth)
Service B (SamlRegisteredService): uses SAML2 with CAS as the IdP
If we first sign into Service A successfully using Username, Password, and
MFA Token and then attempt to navigate to the URL for Service B this works
well (as expected).
However, if we attempt to specify bypass rules for bypassing MFA based on a
principal attribute (either using cas.properties or groovy script), when we
access Service B after successfully authenticating with Service A, CAS
forces a re-authentication of the user for Service B. This seems to work
fine as long as we do not enable MFA bypass (plain MFA works).
Does anyone have an idea of any additional configuration that might be
required to make MFA bypass work with the SSO sessions preserved across
services?
Regards,
Purush
On Wednesday, August 18, 2021 at 12:47:20 PM UTC-4 Purush wrote:
> Can anyone help us with how to troubleshoot this? We are willing to put in
> the effort, but we do not know how this should work to be able to figure
> out what/where things are not working.
>
> If a user is authenticated using the RegexRegisteredService using username
> and password, then when the same use navigates to another
> SamlRegisteredService, what is the expected flow/communication between the
> SAML service and CAS as the idP and the browser? What information in the
> browser is used by the SAML service to send a request to CAS idP and what
> does/should CAS idP respond with?
>
> If we can get an idea on how this should work (what attributes are passed
> and which components do what checks) we can turn up the logs and try to
> understand what is not working.
>
> If anyone has insight into this, your help will be greatly appreciated.
>
> Regards,
> Purush
>
>
> On Tuesday, August 17, 2021 at 9:48:57 AM UTC-4 Purush wrote:
>
>> Yes, we tried this last night and we are having the same issue.
>>
>> On Tuesday, August 17, 2021 at 9:32:00 AM UTC-4 Olivier Begon wrote:
>>
>>> Purush,
>>>
>>> Have you tried with 6.4.0-RC6 ?
>>>
>>> Thanks.
>>> Olivier
>>>
>>> On Monday, August 16, 2021 at 10:03:35 AM UTC-4 Purush wrote:
>>>
>>>> Was anyone able to get CAS 6.4.0 to work with SAML2 and CAS as the idP?
>>>> We are still unable to get this to work and are not sure where to look?
>>>>
>>>> Our setup:
>>>> Service A (RegexRegisteredService: WildFly based web-application)
>>>> protected by CAS using username, password and MFA (google auth).
>>>> Service B (SamlRegisteredService: Node.js based web application) that
>>>> uses SAML2 and CAS (same server as Service A) as the idP.
>>>>
>>>> We first successfully login into Service A using username, password and
>>>> mfa (google auth).
>>>> {
>>>> "@class" : "org.apereo.cas.services.RegexRegisteredService",
>>>> "serviceId" : "^https://www.somedomain.com/.*";,
>>>> "name" : "App Server",
>>>> "id" : 10000001,
>>>> "attributeReleasePolicy" : {
>>>> "@class" : "org.apereo.cas.services.ReturnAllAttributeReleasePolicy"
>>>> },
>>>> "evaluationOrder" : 10,
>>>> "multifactorPolicy" : {
>>>> "@class" :
>>>> "org.apereo.cas.services.DefaultRegisteredServiceMultifactorPolicy",
>>>> "multifactorAuthenticationProviders" : [ "java.util.LinkedHashSet",
>>>> [ "mfa-gauth" ] ],
>>>> "bypassEnabled" : "false"
>>>> }
>>>> }
>>>>
>>>> We next navigate to Service B. We see the SAML request from Service 2
>>>> in CAS logs, but Service B redirects us back to the login screen.
>>>> {
>>>> "@class" :
>>>> "org.apereo.cas.support.saml.services.SamlRegisteredService",
>>>> "serviceId" : "data-server",
>>>> "name" : "Data Server",
>>>> "id" : 10000002,
>>>> "attributeReleasePolicy" : {
>>>> "@class" : "org.apereo.cas.services.ReturnAllAttributeReleasePolicy"
>>>> },
>>>> "metadataLocation" : "/etc/cas/saml/data-server-10000002",
>>>> "evaluationOrder" : 10,
>>>> "multifactorPolicy" : {
>>>> "@class" :
>>>> "org.apereo.cas.services.DefaultRegisteredServiceMultifactorPolicy",
>>>> "multifactorAuthenticationProviders" : [ "java.util.LinkedHashSet",
>>>> [ "mfa-gauth" ] ],
>>>> "bypassEnabled": false
>>>> }
>>>> }
>>>>
>>>>
>>>> We are expecting the SAML request to be authenticated by CAS and that
>>>> we do not need to log back into Service B. If we log back in using the
>>>> same
>>>> username password, we gain access to Service B - we are assuming we now
>>>> have 2 sessions active - one for Service A and one for Service B.
>>>>
>>>> If the try this in the reverse order (Service B first and then Service
>>>> A) we have the same issue with Service A redirecting us back to the login
>>>> screen.
>>>>
>>>> What could we be missing? Where should we look for more information?
>>>> Any help will be greatly appreciated.
>>>>
>>>> Regards,
>>>> Purush
>>>>
>>>>
>>>>
>>>>
>>>> On Tuesday, June 29, 2021 at 9:48:06 PM UTC-4 Purush wrote:
>>>>
>>>>> Ray,
>>>>> Thank you for checking. The script is very simple, based on the
>>>>> value of an LDAP attribute for the user, it decides where MFA should be
>>>>> bypassed or not. Content of script below:
>>>>>
>>>>> Regards,
>>>>> Purush
>>>>>
>>>>>
>>>>> =======================
>>>>> import java.util.*
>>>>>
>>>>> def boolean run(final Object... args) {
>>>>> def authentication = args[0]
>>>>> def principal = args[1]
>>>>> def registeredService = args[2]
>>>>> def provider = args[3]
>>>>> def logger = args[4]
>>>>> def httpRequest = args[5]
>>>>>
>>>>> // Ignore MFA for everyone, except if homePastalAddress = dev
>>>>> logger.info("Evaluating multifactor authn bypass rules for {}",
>>>>> principal)
>>>>> if ( principal.attributes["homePostalAddress"].contains("dev") ) {
>>>>> logger.info("homePostalAddress is dev, bypassing MFA...")
>>>>> return false
>>>>> } else {
>>>>> logger.info("homePostalAddress is not dev, redirecting to
>>>>> MFA...")
>>>>> return true
>>>>> }
>>>>> }
>>>>>
>>>>>
>>>>>
>>>>> On Tuesday, June 29, 2021 at 4:49:08 PM UTC-4 Ray Bon wrote:
>>>>>
>>>>>> Purush,
>>>>>>
>>>>>> Does the groovy script modify the TGC or the login session?
>>>>>>
>>>>>> Perhaps a property that the script depended on has been renamed/moved
>>>>>> in RC5.
>>>>>>
>>>>>> Can you post the script?
>>>>>>
>>>>>> Ray
>>>>>>
>>>>>> On Tue, 2021-06-29 at 05:19 -0700, Purush wrote:
>>>>>>
>>>>>> Notice: This message was sent from outside the University of Victoria
>>>>>> email system. Please be cautious with links and sensitive information.
>>>>>>
>>>>>> I have been testing this further and realized I failed to mention
>>>>>> part of the scenario. We had GoogleAuth MFA turned on and have a groovy
>>>>>> script that decides whether a user should be presented with the MFA
>>>>>> challenge or if MFA should be bypassed.
>>>>>>
>>>>>> It seems like the SSO works fine (silently logging in across Username
>>>>>> Password and SAML2 without a challenge) for users who are challenged for
>>>>>> MFA.
>>>>>> But if the MFA is bypassed for a user, it seems to skip something
>>>>>> that prevents a silent login across services.
>>>>>>
>>>>>> Any thoughts on where I should look to resolve this? It is critical
>>>>>> for us get this to work with the the groovy script to bypass MFA.
>>>>>>
>>>>>> Regards,
>>>>>> Purush
>>>>>>
>>>>>>
>>>>>> On Friday, June 18, 2021 at 12:36:28 PM UTC-4 Purush wrote:
>>>>>>
>>>>>> Does anyone have suggestions on what we could be doing wrong?
>>>>>>
>>>>>> We'd be happy to drill deeper into the source code if we could get an
>>>>>> idea on where to look to identify the cause of the duplicate TGC cookies
>>>>>> being created.
>>>>>>
>>>>>> Regards,
>>>>>> Purush
>>>>>>
>>>>>>
>>>>>> On Wednesday, June 16, 2021 at 7:05:20 PM UTC-4 Purush wrote:
>>>>>>
>>>>>> Ray,
>>>>>> Thank you. I have not set the maxAge in the cas config.
>>>>>> Additional data: this was working fine when we tried it before with the
>>>>>> 6.4.0 SNAPSHOT in Feb, It does not seem to be working with the RC5
>>>>>> version.
>>>>>>
>>>>>> Regards,
>>>>>>
>>>>>> On Wednesday, June 16, 2021 at 6:50:22 PM UTC-4 Ray Bon wrote:
>>>>>>
>>>>>> Purush,
>>>>>>
>>>>>> Check your cas config for cookie settings. Is Max-Age=0?
>>>>>>
>>>>>> Ray
>>>>>>
>>>>>> On Wed, 2021-06-16 at 13:53 -0700, Purush wrote:
>>>>>>
>>>>>> Notice: This message was sent from outside the University of Victoria
>>>>>> email system. Please be cautious with links and sensitive information.
>>>>>>
>>>>>>
>>>>>> I am not sure if this is related to the above issue, but when I turn
>>>>>> on browser debugs and look at the cookie being set, I see 2 Set-Cookie
>>>>>> entries in the same Response Headers after the first authentication:
>>>>>>
>>>>>> Set-Cookie:
>>>>>> TGC=eyJhbGciOiJIUzUxMiIsInR5cCI6IkpXVCJ9.ZXlKNmFYQWlPaUpFUlVZaUxDSmhiR2NpT2lKa2FYSWlMQ0psYm1NaU9pSkJNVEk0UTBKRExVaFRNalUySWl3aVkzUjVJam9pU2xkVUlpd2lkSGx3SWpvaVNsZFVJbjAuLnRBT29mZ01vOFU1UDNwOUxfSzIyR0EuaElPejZpVkZRajhfZDV3TFNrNkxIbFFldFhmZGdnR0hxeVFLUkxjUjE5VU0wdTNaZUVJU2N6YTNPN2NDOEE0NEVMV2JGRWNfRGlESGpsWllBOEN3NG5zdE51Mllad2hfcXNVSlU3bWFsVzFMTTY5ODZJMG5laVNGNXVNR1VES3cxcmVxNHpGOVAzS1JaWHN5WnFKc0tSTlNmNlUyaTRwMWpnaVFiNFVSbHNBSFlUVXd4eGJfV0pXOTFqSERRZTZBTmY2ME5ETkh6a0ZycWxGWXFDTWgzVVVXS29wTlEzYnctNWtYY2F4Xzc4b0dMMldtR3loRTBRSWMyR1V6c1NRNUZ4MWdFaG9udWFSSy1sMV9FMl9yc1EuM09CZWlzY3NjZlA1V3RpUEU2WlVvUQ.M53qeeZbAn8vK3qbCfwhJkH1qp9I-215Oo1U9FdctNgGSkzsBiO1dSrnLAR4bPLbKG9pEvhYUe3HiXaYbkkQng;
>>>>>>
>>>>>> Path=/sso/; SameSite=None; Secure; HttpOnly
>>>>>>
>>>>>> Set-Cookie: TGC=""; Version=1; Path=/sso/; Secure; HttpOnly;
>>>>>> Max-Age=0; Expires=Thu, 01-Jan-1970 00:00:00 GMT; Comment="CAS Cookie"
>>>>>>
>>>>>>
>>>>>>
>>>>>> Regards,
>>>>>>
>>>>>> On Wednesday, June 16, 2021 at 4:48:51 PM UTC-4 Purush wrote:
>>>>>>
>>>>>> Hello All,
>>>>>> I am testing the latest CAS 6.4.0-RC5 build with 2
>>>>>> services registered with CAS.
>>>>>> Service A: uses Username, Password and MFA (GoogleAuth)
>>>>>> Service B: uses SAML2 with CAS as the IdP
>>>>>>
>>>>>> I first sign first into Service A successfully using Username,
>>>>>> Password, Token and then attempt to navigate to the URL for Service B.
>>>>>> My
>>>>>> expectation is that CAS will recognize the SSO session that already
>>>>>> active
>>>>>> and grant access to Service B. However, CAS seems to redirect me back to
>>>>>> the login screen again. If I authenticate again using the same
>>>>>> credentials,
>>>>>> then I am able to access Service B. The same issue occurs in the reverse
>>>>>> scenario as well (Service B first, Service A next).
>>>>>>
>>>>>> After examining the logs with Trace turned on, I see a CAS log entry
>>>>>> indicating the Ticket Granting Cookie was blank when trying to access
>>>>>> the
>>>>>> second service.
>>>>>>
>>>>>> Is there a known issue with SSO sessions/TGC cookies with the RC5
>>>>>> release or additional config that needs to be completed?
>>>>>>
>>>>>> Regards,
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
--
- 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 [email protected].
To view this discussion on the web visit
https://groups.google.com/a/apereo.org/d/msgid/cas-user/8f1998a5-f3b5-4e91-85f6-a05167b86fcbn%40apereo.org.
