CAS 6.6.15 - Throttling REST Authentication

124 views
Skip to first unread message

Kostas Kalevras

unread,
Jan 17, 2024, 9:34:32 PM1/17/24
to CAS Community
Hello all

Using CAS 6.6.15 in a Docker setup with LDAP user repository.

CAS/SAML/OIDC authentication works with no problem. Throttling CAS auth requests also works without a problem.

The relevant throtlling configuration in cas.properties is as follows:

# Failure Throttling
cas.authn.throttle.failure.threshold=1
cas.authn.throttle.failure.code=AUTHENTICATION_FAILED
cas.authn.throttle.failure.range-seconds=30
cas.authn.throttle.core.username-parameter=username

We have enabled REST Authentication which works without a problem:

/# curl -sk https://sso-server:8443/cas/v1/users -d 'username=test&password=test'|jq .authentication.credentials
[
  {
    "@class": "org.apereo.cas.authentication.metadata.BasicCredentialMetaData",
    "id": "test",
    "credentialClass": "org.apereo.cas.authentication.credential.UsernamePasswordCredential"
  }
]

REST and throttling implementation in build.gradle:

    implementation "org.apereo.cas:cas-server-support-throttle"
    implementation "org.apereo.cas:cas-server-support-rest"

Yet no matter how we try, throttling REST auth requests does not work. Looking at the relevant code, I see that throttling is implemented. Nevertheless, the debug line about "Activating authentication throttling for REST endpoints..." does not seem to be called.

My fear is for a race condition where REST is initialized before throttling and the check for the relevant bean fails.

Any help would be appreciated.

Kostas Kalevras

unread,
Jan 22, 2024, 9:09:22 AM1/22/24
to CAS Community, Kostas Kalevras
Just an update. Replacing @ConditionalOnBean with @DependsOn in order to make sure that the REST protocol is initialized after Authentication Throttling seems to fix things. So I guess there actually is a race condition with REST being initialzed before throttling.

Not sure if there's any other way to initialize beans with a specific order without code changes.

Petr Bodnár

unread,
Jan 22, 2024, 2:57:27 PM1/22/24
to CAS Community, Kostas Kalevras
Hi Kostas,

thanks for sharing your findings, it does seem like a bug. For me, even just removing the "@ConditionalOnBean..." line worked as well (done in a custom config class though).

It looks like that the aforementioned line is redundant, because the bean referenced by the annotation is used conditionally via Spring's ObjectProvider anyway - by calling "authenticationThrottlingExecutionPlan.ifAvailable(plan -> { ..." on the provider instance.

Regards
Petr
Reply all
Reply to author
Forward
0 new messages