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
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
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 getti
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.
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-casusera
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
surrog
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
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.aut
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
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...@smythc
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]
12 matches
Mail list logo