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
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
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
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
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
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.
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
