Purush, Is homePostalAddress part of the global attributes (those obtained on authentication)?
https://apereo.github.io/cas/6.3.x/configuration/Configuration-Properties.html#ldap-authentication https://apereo.github.io/cas/6.3.x/configuration/Configuration-Properties.html#authentication-attributes Try these loggers to see if the attribute is available <!-- DEBUG Found principal attributes [...] for [username] Attribute policy [???] allows release of [...] for [username] Final collection of attributes allowed are: [...] --> <AsyncLogger name="org.apereo.cas.services.AbstractRegisteredServiceAttributeReleasePolicy" level="debug"/> <!-- DEBUG Skipping access strategy policy - when no attributes rules are defined These required attributes [...] are examined against [...] before service can proceed - when attrubutes are defined --> <AsyncLogger name="org.apereo.cas.services.DefaultRegisteredServiceAccessStrategy" level="debug"/> <!-- DEBUG CAS will not authorize the release of ... given the service is denied access to all attributes --> <AsyncLogger name="org.apereo.cas.services.DenyAllAttributeReleasePolicy" level="debug"/> Ray On Wed, 2021-08-18 at 14:09 -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 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<http://logger.info>("Evaluating multifactor authn bypass rules for {}", principal) if ( principal.attributes["homePostalAddress"].contains("dev") ) { logger.info<http://logger.info>("homePostalAddress is dev, bypassing MFA...") return false } else { logger.info<http://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/2de58244ef5529278753206dc57e4f75a724a8f6.camel%40uvic.ca.
