Took me a few to get a few different container versions ready, and it looks like it was a bug. We have been using surrogate for only a few months and have been using a 'master' branch container as primary on our app controller for a while and it doesn't occur and fixed in master many moons ago. See here, https://github.com/apereo/cas/commit/3a8cb528850d3822dbeba7a73f7e3bf85d3d9abc , you could switch to latest tag in gradle if you dont want to build off master, tag is 7.0.0-RC6 ,
On Wednesday, July 26, 2023 at 11:54:54 AM UTC-5 [email protected] wrote: > Thanks for your reply John. > > Read the docs repeatedly and somehow kept reading that as admin+surrogate > rather than surrogate+admin. > > However, there is still a default "web flow" issue between MFA and > surrogate. > > When tested as +admin with the drop down it triggers simple MFA but > bypasses surrogate drop down selection. > > When tested as you suggested as surrogate+admin (which does correctly > authenticate), it bypasses MFA and does correctly bring up the surrogate. > > > Should point out that if MFA groovy script returns null it will correctly > display the surrogate drop down. So If I disable MFA, which is what we > currently have for our internal logins, then surrogate selection works. > > > On Wednesday, July 26, 2023 at 9:32:36 AM UTC-5 John wrote: > >> 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/3869f297-caa3-4850-b4fd-0781346b5f71n%40apereo.org.
