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/af64370a-69fe-4ff2-8b55-85b48a218e60n%40apereo.org.
