Re: [cas-user] Simple MFA to Surrogate bypasses surrogate selection
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"]
>> }
>>
[cas-user] MFA expiration with couchDb
CAS 6.6.6
Have Simple MFA expiration working in production with couchDb, but had
noticed an issue.
No matter how configured, the expiration of the MFA couchDb record is
always written at 100 years from record creation date.
Only work around I could find for this was to add a "by_not_processed "
view to couchDb that finds newly created MFA cache entries in order modify
them with a nightly process to the correct the expiration (to for instance
7 days out). This does work very nicely in conjunction with multi-device
MFA.
Either the timed CAS cleanup, or querying the expired record will cause it
to be removed which then triggers the need for the user to re-MFA.
Sharing the following in case others run into this issue, and in the case
they also discover the auto-create is not working with couchDb MFA caching.
Added the by_not_processed view, as well as the index (2nd definition)
Combed through every setting I could find from both the documents and the
master property lists. Nothing seemed to affect the expiration. Perhaps I
missed a setting, or there is an undocumented setting, or a problem crept
in. In any case this is a functional work around.
{
"_id": "_design/CouchDbMultifactorAuthenticationTrustRecord",
"_rev": "10-f5c3b2d1d2d76830b88fe50965fbbd0c",
"views": {
"all": {
"map": "function(doc) { if (doc.recordKey && doc.principal &&
doc.deviceFingerprint && doc.recordDate) { emit(doc._id, doc) } }"
},
"by_recordKey": {
"map": "function(doc) { if (doc.principal && doc.deviceFingerprint &&
doc.recordDate) { emit(doc.recordKey, doc) } }"
},
"by_recordDate": {
"map": "function(doc) { if (doc.principal && doc.deviceFingerprint &&
doc.recordDate) { emit(doc.recordDate, doc) } }"
},
"by_expirationDate": {
"map": "function(doc) { if (doc.principal && doc.deviceFingerprint &&
doc.expirationDate) { emit(doc.expirationDate, doc) } }"
},
"by_principal": {
"map": "function(doc) { if (doc.principal && doc.deviceFingerprint &&
doc.recordDate) { emit(doc.principal, doc) } }"
},
"by_id": {
"map": "function(doc) { if (doc.principal && doc.deviceFingerprint &&
doc.recordDate) { emit(doc.id, doc) } }"
},
"by_principal_date": {
"map": "function(doc) { if (doc.recordKey && doc.principal &&
doc.deviceFingerprint && doc.recordDate) { emit([doc.principal,
doc.recordDate], doc) } }"
},
"by_all": {
"map": "function(doc) { if (doc.recordKey) { emit([doc.recordKey],
doc) } }"
},
"by_not_processed": {
"map": "function(doc) { if (doc.recordKey && !doc.processed) {
emit([doc.recordKey], doc) } }"
}
},
"lists": {},
"shows": {},
"language": "javascript",
"filters": {}
}
{
"_id": "_design/531fa4a2dcce623b3bf528d83ef5a85e0cafffe4",
"_rev": "3-14798c189251a398d868ae55b8ea2e33",
"language": "query",
"views": {
"processed-json-index": {
"map": {
"fields": {
"processed": "asc"
},
"partial_filter_selector": {}
},
"reduce": "_count",
"options": {
"def": {
"fields": [
"processed"
]
}
}
}
}
}
In batch java job have something like the following to update the
expiration date.
...
List mfaList =
dbClient.view("CouchDbMultifactorAuthenticationTrustRecord/by_not_processed")
.includeDocs(true)
.limit(200)
.query(CasMfaCache.class);
if ((mfaList != null) && (mfaList.size() > 0)) {
for (CasMfaCache mfa : mfaList) {
/*
sample recordDate, and expirationDates with expected format in
record
"recordDate": "2023-06-17T19:49:39Z",
"expirationDate": "2123-06-17T19:49:39.000+00:00"
*/
LocalDate ld = LocalDate.parse(mfa.getRecordDate().substring(0,
10), dateFormatter).plusDays(expireInXDays);
String expirationDate = ld.format(dateFormatter) +
mfa.getRecordDate().substring(10, 19) + ".000+00:00";
mfa.setExpirationDate(expirationDate);
mfa.setProcessed("Y");
dbClient.update(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/34e77605-5cf4-478e-91f4-8720d3a1bcdcn%40apereo.org.
[cas-user] Re: Errors when Upgrading from 6.4 to 6.5
Try adding to your build.gradle ... implementation "org.springframework:spring-context-indexer:5.3.28" annotationProcessor "org.springframework:spring-context-indexer:5.3.28" On Tuesday, July 25, 2023 at 3:20:45 PM UTC-5 neilbh...@gmail.com wrote: > When I upgrade CAS from 6.4 to 6.5 I am getting the error: > > cas_6x_overlay-casuseradmin-1 | *** > cas_6x_overlay-casuseradmin-1 | APPLICATION FAILED TO START > cas_6x_overlay-casuseradmin-1 | *** > cas_6x_overlay-casuseradmin-1 | > cas_6x_overlay-casuseradmin-1 | Description: > cas_6x_overlay-casuseradmin-1 | > cas_6x_overlay-casuseradmin-1 | Parameter 0 of method > defaultCasWebflowAuthenticationExceptionHandler in > org.apereo.cas.web.flow.config.CasCoreWebflowConfiguration$CasCoreWebflowExceptionHandlingConfiguration > > required a bean of type > 'org.apereo.cas.web.flow.authentication.CasWebflowExceptionCatalog' that > could not be found. > cas_6x_overlay-casuseradmin-1 | > cas_6x_overlay-casuseradmin-1 | > cas_6x_overlay-casuseradmin-1 | Action: > cas_6x_overlay-casuseradmin-1 | > cas_6x_overlay-casuseradmin-1 | Consider defining a bean of type > 'org.apereo.cas.web.flow.authentication.CasWebflowExceptionCatalog' in your > configuration. > cas_6x_overlay-casuseradmin-1 | > > cas_6x_overlay-casuseradmin-1 | 25-Jul-2023 18:30:42.347 SEVERE [main] > org.apache.catalina.startup.HostConfig.deployDirectory Error deploying web > application directory [/usr/local/tomcat/webapps/cas] > cas_6x_overlay-casuseradmin-1 |java.lang.IllegalStateException: > Error starting child > cas_6x_overlay-casuseradmin-1 |at > org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:686) > cas_6x_overlay-casuseradmin-1 |at > org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:658) > cas_6x_overlay-casuseradmin-1 |at > org.apache.catalina.core.StandardHost.addChild(StandardHost.java:662) > cas_6x_overlay-casuseradmin-1 |at > org.apache.catalina.startup.HostConfig.deployDirectory(HostConfig.java:1184) > cas_6x_overlay-casuseradmin-1 |at > org.apache.catalina.startup.HostConfig$DeployDirectory.run(HostConfig.java:1932) > cas_6x_overlay-casuseradmin-1 |at > java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515) > cas_6x_overlay-casuseradmin-1 |at > java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264) > cas_6x_overlay-casuseradmin-1 |at > org.apache.tomcat.util.threads.InlineExecutorService.execute(InlineExecutorService.java:75) > cas_6x_overlay-casuseradmin-1 |at > java.base/java.util.concurrent.AbstractExecutorService.submit(AbstractExecutorService.java:118) > cas_6x_overlay-casuseradmin-1 |at > org.apache.catalina.startup.HostConfig.deployDirectories(HostConfig.java:1094) > cas_6x_overlay-casuseradmin-1 |at > org.apache.catalina.startup.HostConfig.deployApps(HostConfig.java:476) > cas_6x_overlay-casuseradmin-1 |at > org.apache.catalina.startup.HostConfig.start(HostConfig.java:1617) > cas_6x_overlay-casuseradmin-1 |at > org.apache.catalina.startup.HostConfig.lifecycleEvent(HostConfig.java:318) > cas_6x_overlay-casuseradmin-1 |at > org.apache.catalina.util.LifecycleBase.fireLifecycleEvent(LifecycleBase.java:123) > cas_6x_overlay-casuseradmin-1 |at > org.apache.catalina.util.LifecycleBase.setStateInternal(LifecycleBase.java:423) > cas_6x_overlay-casuseradmin-1 |at > org.apache.catalina.util.LifecycleBase.setState(LifecycleBase.java:366) > cas_6x_overlay-casuseradmin-1 |at > org.apache.catalina.core.ContainerBase.startInternal(ContainerBase.java:893) > cas_6x_overlay-casuseradmin-1 |at > org.apache.catalina.core.StandardHost.startInternal(StandardHost.java:795) > cas_6x_overlay-casuseradmin-1 |at > org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:183) > cas_6x_overlay-casuseradmin-1 |at > org.apache.catalina.core.ContainerBase$StartChild.call(ContainerBase.java:1328) > cas_6x_overlay-casuseradmin-1 |at > org.apache.catalina.core.ContainerBase$StartChild.call(ContainerBase.java:1318) > cas_6x_overlay-casuseradmin-1 |at > java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264) > cas_6x_overlay-casuseradmin-1 |at > org.apache.tomcat.util.threads.InlineExecutorService.execute(InlineExecutorService.java:75) > cas_6x_overlay-casuseradmin-1 |at > java.base/java.util.concurrent.AbstractExecutorService.submit(AbstractExecutorService.java:140) > cas_6x_overlay-casuseradmin-1 |at > org.apache.catalina.core.ContainerBase.startInternal(ContainerBase.java:866) > cas_6x_overlay
Re: [cas-user] Simple MFA to Surrogate bypasses surrogate selection
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
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] Errors when Upgrading from 6.4 to 6.5
When I upgrade CAS from 6.4 to 6.5 I am getting the error: cas_6x_overlay-casuseradmin-1 | *** cas_6x_overlay-casuseradmin-1 | APPLICATION FAILED TO START cas_6x_overlay-casuseradmin-1 | *** cas_6x_overlay-casuseradmin-1 | cas_6x_overlay-casuseradmin-1 | Description: cas_6x_overlay-casuseradmin-1 | cas_6x_overlay-casuseradmin-1 | Parameter 0 of method defaultCasWebflowAuthenticationExceptionHandler in org.apereo.cas.web.flow.config.CasCoreWebflowConfiguration$CasCoreWebflowExceptionHandlingConfiguration required a bean of type 'org.apereo.cas.web.flow.authentication.CasWebflowExceptionCatalog' that could not be found. cas_6x_overlay-casuseradmin-1 | cas_6x_overlay-casuseradmin-1 | cas_6x_overlay-casuseradmin-1 | Action: cas_6x_overlay-casuseradmin-1 | cas_6x_overlay-casuseradmin-1 | Consider defining a bean of type 'org.apereo.cas.web.flow.authentication.CasWebflowExceptionCatalog' in your configuration. cas_6x_overlay-casuseradmin-1 | > cas_6x_overlay-casuseradmin-1 | 25-Jul-2023 18:30:42.347 SEVERE [main] org.apache.catalina.startup.HostConfig.deployDirectory Error deploying web application directory [/usr/local/tomcat/webapps/cas] cas_6x_overlay-casuseradmin-1 |java.lang.IllegalStateException: Error starting child cas_6x_overlay-casuseradmin-1 |at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:686) cas_6x_overlay-casuseradmin-1 |at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:658) cas_6x_overlay-casuseradmin-1 |at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:662) cas_6x_overlay-casuseradmin-1 |at org.apache.catalina.startup.HostConfig.deployDirectory(HostConfig.java:1184) cas_6x_overlay-casuseradmin-1 |at org.apache.catalina.startup.HostConfig$DeployDirectory.run(HostConfig.java:1932) cas_6x_overlay-casuseradmin-1 |at java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515) cas_6x_overlay-casuseradmin-1 |at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264) cas_6x_overlay-casuseradmin-1 |at org.apache.tomcat.util.threads.InlineExecutorService.execute(InlineExecutorService.java:75) cas_6x_overlay-casuseradmin-1 |at java.base/java.util.concurrent.AbstractExecutorService.submit(AbstractExecutorService.java:118) cas_6x_overlay-casuseradmin-1 |at org.apache.catalina.startup.HostConfig.deployDirectories(HostConfig.java:1094) cas_6x_overlay-casuseradmin-1 |at org.apache.catalina.startup.HostConfig.deployApps(HostConfig.java:476) cas_6x_overlay-casuseradmin-1 |at org.apache.catalina.startup.HostConfig.start(HostConfig.java:1617) cas_6x_overlay-casuseradmin-1 |at org.apache.catalina.startup.HostConfig.lifecycleEvent(HostConfig.java:318) cas_6x_overlay-casuseradmin-1 |at org.apache.catalina.util.LifecycleBase.fireLifecycleEvent(LifecycleBase.java:123) cas_6x_overlay-casuseradmin-1 |at org.apache.catalina.util.LifecycleBase.setStateInternal(LifecycleBase.java:423) cas_6x_overlay-casuseradmin-1 |at org.apache.catalina.util.LifecycleBase.setState(LifecycleBase.java:366) cas_6x_overlay-casuseradmin-1 |at org.apache.catalina.core.ContainerBase.startInternal(ContainerBase.java:893) cas_6x_overlay-casuseradmin-1 |at org.apache.catalina.core.StandardHost.startInternal(StandardHost.java:795) cas_6x_overlay-casuseradmin-1 |at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:183) cas_6x_overlay-casuseradmin-1 |at org.apache.catalina.core.ContainerBase$StartChild.call(ContainerBase.java:1328) cas_6x_overlay-casuseradmin-1 |at org.apache.catalina.core.ContainerBase$StartChild.call(ContainerBase.java:1318) cas_6x_overlay-casuseradmin-1 |at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264) cas_6x_overlay-casuseradmin-1 |at org.apache.tomcat.util.threads.InlineExecutorService.execute(InlineExecutorService.java:75) cas_6x_overlay-casuseradmin-1 |at java.base/java.util.concurrent.AbstractExecutorService.submit(AbstractExecutorService.java:140) cas_6x_overlay-casuseradmin-1 |at org.apache.catalina.core.ContainerBase.startInternal(ContainerBase.java:866) cas_6x_overlay-casuseradmin-1 |at org.apache.catalina.core.StandardEngine.startInternal(StandardEngine.java:249) cas_6x_overlay-casuseradmin-1 |at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:183) cas_6x_overlay-casuseradmin-1 |at org.apache.catalina.core.StandardService.startInternal(StandardService.java:428) cas_6x_overlay-casuseradmin-1 |
[cas-user] Simple MFA to Surrogate bypasses surrogate selection
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.
Re: ~Re: [cas-user] [CAS 6.6.8] Custom MFA triggers
Maybe Misagh could put in his thoughts on this, but I would argue the
opposite is more true in fact, having custom java code and having to
register, etc.. rely's on way MORE base code in cas then the groovy
methods. If you take a look at the way groovy scripts are written in cas it
is mainly a simple execute groovy method passing the parameters and just
reading the results. That code itself doesn't change much, we had thousands
of lines of custom java code before the 6.x days, for all kinds of things.
Now we maintain 2 individual java class files and working to get those
changes pushed into cas, just need to write the test cases and scenarios.
One of the benefits to using groovy is the no compile time, they don't need
to be compiled with your overlay! most if not all groovy scripts are
reloaded on demand, when changed and take affect immediately with no
restarts which makes a huge difference.
Not sure why the other posters simple-mfa wouldnt work but works no problem
for us, it could be the trigger type being used, there is the
cas.authn.mfa.core.provider-selector-groovy-script
and what we use, cas.authn.mfa.groovy-script and we have some
vendors/external services that use database auth and mfa is fine, we also
use surrogate and in our groovy we have parts written to either
bypass/force for surrogate situations.
We have been using CAS since the 3.x days and when groovy webflow came
along, it was a blessing!! It is s much easier to maintain then custom
java code. See the attached, this is one of about 4 different flow
modifiers, using the "properties" in a service definition, we utilize this
flow to inject custom post fields for services that require a POST response
instead of REDIRECT.
I think, in my opinion, groovy is way more sustainable to maintain then the
other.
Thanks,
John
On Tuesday, July 25, 2023 at 7:18:07 AM UTC-5 spfma...@e.mail.fr wrote:
> Hi,
> Thanks for your reply.
> From what I have read in the recommendations in the docs, scripting is ok
> but coding is better and more sustainable (build time vs run time I guess).
> So I am trying to understand how to implement something like what is
> described here :
> https://apereo.github.io/cas/6.6.x/mfa/Configuring-Multifactor-Authentication-Triggers-Custom.html
> But so far I don't even know where to put the code, how to even have a
> single debug log line.
> Thanks for this example (I think I saw it a couple of monthes ago),if will
> follow this way if it's the right one too.
> But I can't forget I have to replicate an old "login-webflow.xml", which
> seems to be done programmatically only in current version.
> Regards
>
>
> Le 21-Jul-2023 20:00:53 +0200, rb...@uvic.ca a écrit:
>
> This may provide some direction
> https://fawnoos.com/2018/11/22/cas5-groovy-mfa/
> There may be other posts on this site that can help.
>
> Ray
>
> On Fri, 2023-07-21 at 08:49 +0200, spfma.tech via CAS Community wrote:
>
> Notice: This message was sent from outside the University of Victoria
> email system. Please be cautious with links and sensitive information.
>
> Hi,
> I would like to implement some conditional MFA scenarios (using a
> different provider depending on the network is the first one), but reading
> https://apereo.github.io/cas/6.6.x/mfa/Configuring-Multifactor-Authentication-Triggers-Custom.html
>
> does not provide a lot of help.
> Is there some code snippet available somewhere I could use as an example ?
> Regards
>
> --
> FreeMail powered by mail.fr
>
>
>
>
>
>
>
> --
> FreeMail powered by mail.fr
--
- 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/fd892674-8cea-4f49-a814-568482278b47n%40apereo.org.
if (webflow.containsFlowState(loginFlow,
CasWebflowConstants.STATE_ID_GENERATE_SERVICE_TICKET)) {
logger.debug("Webflow: Found state that modifys the
generateServiceTicketAction");
def state = webflow.getState(loginFlow,
CasWebflowConstants.STATE_ID_GENERATE_SERVICE_TICKET, ActionState.class)
logger.debug("Webflow: State id is {}", state.id);
state.getExitActionList().add({ requestContext ->
def flowScope = requestContext.flowScope
def httpRequest =
WebUtils.getHttpServletRequestFromExternalWebflowContext(requestContext);
def requestScope = requestContext.getRequestScope();
def authentication = WebUtils.getAuthentication(requestContext) as
Authentication;
def principal = authentication.getPrincipal() as Princ
Re: [cas-user] [CAS 6.6.8] Custom MFA triggers
Hi, Thansk for your file, I will have a look at it. And I think I will have to study the whole code in fact, I don't know who is triggering what and how for now. Regards Le 21-Jul-2023 20:33:38 +0200, jbanner6...@gmail.com a crit: This is slimmed down using the groovy script trigger, cas.authn.mfa.groovy-script.location from here, https://apereo.github.io/cas/6.6.x/mfa/Configuring-Multifactor-Authentication-Triggers-Groovy.html . I left in the bits pertaining basically to your case, gets the clients ip address and compares against a cidr list using springs IpAddressMatcher function. There is a little more in it, we also modified the groovy trigger to accept an array, and not just mfa-composite. If you want to see the change, its a single file change, easy. Just need to get it better and submit pull request. On Friday, July 21, 2023 at 1:58:27 AM UTC-5 spfma...@e.mail.fr wrote: Hi, I would like to implement some conditional MFA scenarios (using a different provider depending on the network is the first one), but reading https://apereo.github.io/cas/6.6.x/mfa/Configuring-Multifactor-Authentication-Triggers-Custom.html does not provide a lot of help. Is there some code snippet available somewhere I could use as an example ? Regards - FreeMail powered by mail.fr -- - 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/aefaeec6-6f7c-444f-9575-d22dd50f8121n%40apereo.org. - FreeMail powered by mail.fr -- - 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/93ca14a41f22d818ca05fbc58be3dd0901bb%40mail.de.
~Re: [cas-user] [CAS 6.6.8] Custom MFA triggers
Hi, Thanks for your reply. From what I have read in the recommendations in the docs, scripting is ok but coding is better and more sustainable (build time vs run time I guess). So I am trying to understand how to implement something like what is described here : https://apereo.github.io/cas/6.6.x/mfa/Configuring-Multifactor-Authentication-Triggers-Custom.html But so far I don't even know where to put the code, how to even have a single debug log line. Thanks for this example (I think I saw it a couple of monthes ago),if will follow this way if it's the right one too. But I can't forget I have to replicate an old "login-webflow.xml", which seems to be done programmatically only in current version. Regards Le 21-Jul-2023 20:00:53 +0200, r...@uvic.ca a crit: This may provide some direction https://fawnoos.com/2018/11/22/cas5-groovy-mfa/ There may be other posts on this site that can help. Ray On Fri, 2023-07-21 at 08:49 +0200, spfma.tech via CAS Community wrote: Notice: This message was sent from outside the University of Victoria email system. Please be cautious with links and sensitive information.Hi, I would like to implement some conditional MFA scenarios (using a different provider depending on the network is the first one), but readinghttps://apereo.github.io/cas/6.6.x/mfa/Configuring-Multifactor-Authentication-Triggers-Custom.html does not provide a lot of help. Is there some code snippet available somewhere I could use as an example ? Regards - FreeMail powered by mail.fr - FreeMail powered by mail.fr -- - 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/b7c144d168656ea4487d9179c04f8da520d19b6a%40mail.de.
Re: [cas-user] [CAS 6.6.8] Custom MFA triggers
Hi, Thanks for your answer. So far we don't rely on surrogate, just using a simple LDAP backend. But it's nice to now there are some constraints and bypasses. Yes, injecting some parameters to make service names more dynamic is a good idea. Regards Le 22-Jul-2023 06:34:41 +0200, tosl...@smythco.com a crit: Recently deployed a solution that segregates traffic originating externally versus internally. The deployment is also using MFA. In this case authenticating name/pass against DBMS. External/Internal each handled by its own service with a different pool of users allowed to authenticate for each service. Each pool has an extra property that denotes "internal" vs "external". Possible to examine this internal vs external property within groovy script to trigger use of different MFA providers, or in our case to only trigger it for external. Found 2 workable solutions for segregating external vs external traffic in regards to services. Both make use of regex in relation to the service id. This is a relatively straightforward setup if using distinct domains for internal vs external traffic. Also possible (but more difficult) with single domain name using proxy pre-detection of internal vs external traffic and embedding extra parameter for external (public) traffic within service parameter In either case, External vs Internal service is selected based on serviceid regex approach. Both are possible, but due to legacy requirements we used the second option. Def recommend the first option if that is a fit for your environment. Much more straightforward. Note that if also planning on using simple DBMS surrogate that it is not compatible with simple MFA. Activation of simple MFA through groovy will not chain to surrogate process and will currently bypass surrogate process. For our purposes use MFA externally and only allow surrogates internally so was not an issue. Went the route above for MFA, rather than detecting internal/external in groovy MFA script, as needed to apply internal/external concept to areas other than just MFA. TONY OSLUND FROM: cas-user@apereo.org on behalf of John DATE: Friday, July 21, 2023 at 1:34 PM TO: CAS Community CC: spfma...@e.mail.fr SUBJECT: [cas-user] Re: [CAS 6.6.8] Custom MFA triggers EXTERNAL SENDER - This email is coming from an external sender outside of Smyth. This is slimmed down using the groovy script trigger, cas.authn.mfa.groovy-script.location from here, https://apereo.github.io/cas/6.6.x/mfa/Configuring-Multifactor-Authentication-Triggers-Groovy.html . I left in the bits pertaining basically to your case, gets the clients ip address and compares against a cidr list using springs IpAddressMatcher function. There is a little more in it, we also modified the groovy trigger to accept an array, and not just mfa-composite. If you want to see the change, its a single file change, easy. Just need to get it better and submit pull request. On Friday, July 21, 2023 at 1:58:27 AM UTC-5 spfma...@e.mail.fr wrote: Hi, I would like to implement some conditional MFA scenarios (using a different provider depending on the network is the first one), but reading https://apereo.github.io/cas/6.6.x/mfa/Configuring-Multifactor-Authentication-Triggers-Custom.html does not provide a lot of help. Is there some code snippet available somewhere I could use as an example ? Regards - FreeMail powered by mail.fr -- - 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/aefaeec6-6f7c-444f-9575-d22dd50f8121n%40apereo.org. - FreeMail powered by mail.fr -- - 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/a2bf276a95e26d9598eb17bc0f3074ed3672c325%40mail.de.
[cas-user] TicketRegistryCleaner Exception - CAS 7.0.0-RC6
Hi, all. I used the delegation identity provider whit github, it run ok, and authorized my account in cas success. But the console log occured a problem as below(tikets registry into redis) 2023-07-25 16:30:00,815 ERROR [org.apereo.cas.util.serialization.AbstractJacksonBackedStringSerializer] - org.apereo.cas.authentication.DefaultAuthentication["credentials"]->java.util.ArrayList[0]->org.apereo.cas.authentication.principal.ClientCredential["credentials"])]> 2023-07-25 16:30:00,815 ERROR [org.apereo.cas.ticket.registry.DefaultTicketRegistryCleaner] - How to fix it , although it doesn't seem to have much impact so far. -- - 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/4bc409c0-ba80-4356-8c61-7912fcc2b023n%40apereo.org.
