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/802975fb-61ec-497f-947e-6351e7040ebcn%40apereo.org.
