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/48f8fcdf-0c0b-4cb1-b48d-fe1cbff99142n%40apereo.org.
