We don't use the surrogate selector at all, the person has to know the account name, and for your login you should be using ` surrogate+adminuser ` and not ` adminuser+surrogate `. Have you turned on debug? Do you have sufficient debug logging messages in your groovy script to track through the whole process? The debug logs can give you a good clue into where or why it would be not working.
On Tuesday, July 25, 2023 at 11:01:59 PM UTC-5 [email protected] wrote: > Really appreciate the quick responses. > > Currently using > cas.authn.mfa.groovy-script.location=file:/somepath/mfa_trigger.groovy > (script contents same as previous message) > > Oddly the adminuser+surrogate approach does not work at all. It won't > authenticate. That has not presented much of an issue as we have so many > potential surrogates that we use the +adminuser/password approach followed > by the drop down selection of the surrogate. > > MFA within our context is in regards to the original +adminuser, not in > regards to MFA for the surrogate themselves (.... so intent is for MFA to > occur and then surrogate selection). > > Correct in assuming that the what appears to be the failure is the bypass > of the surrogate drop down selection when using the +adminuser approach if > the groovy script returns "mfa-simple". If the groovy script returns null > then surrogate drop down selection works correctly with +adminuser/password. > > On Tuesday, July 25, 2023 at 3:49:50 PM UTC-5 John wrote: > >> We use mfa-simple for database auths as well, which groovy mfa are you >> using? cas.authn.mfa.core.provider-selector-groovy-script OR >> cas.authn.mfa.groovy-script >> which is what we use, >> >> >> On Tuesday, July 25, 2023 at 3:41:02 PM UTC-5 Ray Bon wrote: >> >>> Anthony, >>> >>> Does surrogate+username / password approach work, or is it only the >>> surrogate selection that does not work? >>> >>> If I use surrogate+ with a service that requires MFA, it goes through >>> the mfa flow for username and then to service as surrogate. But I do not >>> have any groovy scripts running. >>> >>> Ray >>> >>> On Tue, 2023-07-25 at 10:31 -0700, Anthony Oslund wrote: >>> >>> Notice: This message was sent from outside the University of Victoria >>> email system. Please be cautious with links and sensitive information. >>> >>> >>> Start by stating current deployment uses 6.6.6 with DBMS authentication, >>> not LDAP. >>> >>> Deployment uses the groovy approach for triggering simple MFA. >>> >>> Based on much testing and researching of this archive determined that if >>> simple MFA is activated through groovy script that CAS will bypass >>> surrogate selection. From researching this archive others have run into >>> the same limitation (at least for 6.6.6 and earlier, not sure about later >>> versions). >>> >>> For surrogate logging in using the +username / pass approach and then >>> selecting surrogate from drop down. >>> >>> Surrogate process functions correctly, but only if MFA not selected by >>> the groovy script. This is true even if MFA not required in that exact >>> login instance, having been satisfied by recent/previous login/MFA. For >>> example, groovy script determines that MFA is required for +username... >>> system examines recent MFA cache... regardless if MFA required/not required >>> at this moment.... surrogate process bypassed and authenticated/released >>> parameters are for original +username. >>> >>> Current deployment's security requirements restrict surrogate to >>> internal use only, while only requiring MFA externally so at this time not >>> an issue as both MFA and surrogate are working within their separate >>> external/internal scopes. Future requirements may likely require MFA >>> internally as well, which with current deployment would conflict with >>> internal scope surrogate process. >>> >>> >>> Looking at attached groovy scripts from other posts it appears they are >>> potentially using other MFA ("mfa-gauth", "mfa-webauthn"). Perhaps issue >>> with our deployment is a default web flow issue specific to simple MFA. >>> >>> >>> Simple MFA currently works in all instances, but does not flow to >>> surrogate. If groovy script below returns null for MFA then flow to >>> surrogate selection works as intended. >>> >>> >>> import java.util.* >>> >>> class SampleGroovyProviderSelection { >>> >>> def String run(final Object... args) { >>> def service = args[0] >>> def authentication = args[2] >>> def request = args[3] >>> def logger = args[4] >>> >>> def mfa = null >>> >>> def email = authentication.principal.attributes['email'] >>> def phone = authentication.principal.attributes['phone'] >>> def mfaMode = authentication.principal.attributes['mfa_mode'] >>> >>> logger.info('Groovy script for mfa') >>> logger.info(mfaMode) >>> logger.info(email) >>> logger.info(phone) >>> >>> /* >>> If user lacks both email and phone then bypass MFA >>> >>> If plan is to prevent the user from authenticating if >>> they cannot use MFA, that should be handled further upstream >>> through the DBMS view. It can simply prevent them from >>> ever authenticating (if that is the desired outcome), in >>> which case they will never even get to this point >>> */ >>> if (mfaMode && (email || phone)) { >>> if (mfaMode.contains("Y")) { >>> mfa = ["mfa-simple"] >>> } >>> } >>> return mfa >>> } >>> } >>> >>> -- - 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/23268398-5374-444a-b912-1e024bf35f97n%40apereo.org.
