Re: [cas-user] Simple MFA to Surrogate bypasses surrogate selection

2023-07-27 Thread John
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 tos...@smythco.com 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 tos...@smythco.com 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

Re: [cas-user] Simple MFA to Surrogate bypasses surrogate selection

2023-07-26 Thread Anthony Oslund
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 tos...@smythco.com 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.


 Sim

Re: [cas-user] Simple MFA to Surrogate bypasses surrogate selection

2023-07-26 Thread John
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 tos...@smythco.com 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)
>>>
>>>  

Re: [cas-user] Simple MFA to Surrogate bypasses surrogate selection

2023-07-25 Thread Anthony Oslund
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"]
>>   }
>>   

Re: [cas-user] Simple MFA to Surrogate bypasses surrogate selection

2023-07-25 Thread John
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 cas-user+unsubscr...@apereo.org.
To view this discussion on the web visit 
https://groups.google.com/a/apereo.org/d/msgid/cas-user/e2ec4972-dae9-47f3-9b39-e4a6ac176836n%40apereo.org.


Re: [cas-user] Simple MFA to Surrogate bypasses surrogate selection

2023-07-25 Thread Ray Bon
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 cas-user+unsubscr...@apereo.org.
To view this discussion on the web visit 
https://groups.google.com/a/apereo.org/d/msgid/cas-user/20272de383073f777e3a1ee94e936bbeb5d0d816.camel%40uvic.ca.


[cas-user] Simple MFA to Surrogate bypasses surrogate selection

2023-07-25 Thread Anthony Oslund
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 cas-user+unsubscr...@apereo.org.
To view this discussion on the web visit 
https://groups.google.com/a/apereo.org/d/msgid/cas-user/41604689-dcce-49d9-8be7-54d5026a66a3n%40apereo.org.