[cas-user] Re: JDBC attribute repository sql search by principal
Our model cas 6.6.6 is not exactly as yours (ours is DBMS/Azure rather than
LDAP) but likely parallels the issue so may provide some perspective.
Authentication model where some users authenticated with DBMS name/pass and
others through Azure. Challenge was how to make the released parameters
consistent for the client application regardless of how authenticated.
For DBMS the primary id was the username, for Azure the primary id was the
user's email (as the separate concept of the username was specific to the
DBMS).
For DBMS name/pass not a problem as the username was already the primary
id. For Azure to get translated to username authentication, had to add in
a few additional configuration settings (shown below)
# config properties used with azure and property resolution
...
cas.authn.pac4j.oidc[0].azure.scope=...,email
...
cas.authn.pac4j.oidc[0].azure.principal-attribute-id=email
cas.authn.authentication-attribute-release.enabled=true
# included both primary attributes in attribute release (as well as other
attributes not shown)
cas.authn.attribute-repository.core.default-attributes-to-release=username,email,...
# set the expiration time to 0 to disable caching these attributes in
memory,
# so they will be retrieved each time
cas.authn.attribute-repository.core.expiration-time=0
# use cascade so that the attributes from initial queries can be used as the
# query for the next repository
cas.authn.attribute-repository.core.aggregation=CASCADE
# in our case set merger to REPLACE
cas.authn.attribute-repository.core.merger=REPLACE
...
# setup an attribute repository to be used as a person directory that in
# turn is used to translate Azure release attributes into DBMS username
# attribute AFTER the Azure authentication has taken place
cas.authn.attribute-repository.jdbc[0].id=azuretostandardusername
... (plus other jdbc connection settings)
# has been defined to return at most one row per Azure
email
# and that row will be the user record associated with the email
cas.authn.attribute-repository.jdbc[0].sql=SELECT * FROM
WHERE {0}
cas.authn.attribute-repository.jdbc[0].isolate-internal-queries=false
cas.authn.attribute-repository.jdbc[0].single-row=true
cas.authn.attribute-repository.jdbc[0].require-all-attributes=false
cas.authn.attribute-repository.jdbc[0].attributes.email=email
cas.authn.attribute-repository.jdbc[0].attributes.username=username
...
cas.authn.attribute-repository.jdbc[0].username=email
cas.authn.attribute-repository.jdbc[0].case-insensitive-query-attributes=email->LOWER
...
#
# added for person directory resolution which is used to translate
# from Azure authentication results to DBMS username attribute
#
cas.person-directory.active-attribute-repository-ids=azuretostandardusername
cas.person-directory.attribute-resolution-enabled=true
## these lines left here as documentation
## these are ignored... they are overridden by the
## cas.authn.pac4j.oidc[0].azure.principal-attribute-id=email
## defined above
##
## cas.person-directory.principal-attribute=email
## cas.person-directory.principal-attribute=unique_name
cas.person-directory.principal-resolution-conflict-strategy=first
cas.person-directory.principal-resolution-failure-fatal=false
cas.person-directory.principal-transformation.case-conversion=LOWERCASE
cas.person-directory.return-null=true
# in this case principal id refers to email from azure
cas.person-directory.use-existing-principal-id=true
Added the following to service file to treat the resulting username as the
primary attribute for both
authentication approaches so that after the above attribute repository
(resolution) it would always use
the username as the "usernameAttribute" (for the benefit of the client app)
Note that in this case releasing attributes from azuretostandardusername
"usernameAttributeProvider" : {
"@class" :
"org.apereo.cas.services.PrincipalAttributeRegisteredServiceUsernameProvider",
"usernameAttribute" : "username",
"canonicalizationMode" : "NONE"
},
"attributeReleasePolicy" : {
"principalAttributesRepository" : {
"@class" :
"org.apereo.cas.authentication.principal.DefaultPrincipalAttributesRepository",
"ignoreResolvedAttributes": false,
"attributeRepositoryIds": ["java.util.HashSet", [
"azuretostandardusername" ]],
"mergingStrategy" : "SOURCE"
},
"@class" :
"org.apereo.cas.services.ReturnAllowedAttributeReleasePolicy",
"allowedAttributes" : [ "java.util.ArrayList", [ "email", "username",
...] ]
}
On Wednesday, July 26, 2023 at 11:54:54 AM UTC-5 Pablo Vidaurri wrote:
> Digging thru code:
> SimpleUsernameAttributeProvider.java, method getUsernameAttributeValues,
> there is this line:
> if (query.containsKey(this.usernameAttribute)) { ...}
>
> I see I can perhaps override the username with a userNameAttribute. I have
> not found any config where I can define this value.
>
> Anyone know what property controls this?
>
> -psv
>
> On Wed
[cas-user] CAS 7 startup warnings
When we start CAS 7, a number of warnings are logged. Advice on how to resolve them where feasible would be appreciated. ** WARN [com.hazelcast.cp.CPSubsystem] - <[cas.example.edu]:5701 [dev] [5.2.3] CP Subsystem is not enabled. CP data structures will operate in UNSAFE mode! Please note that UNSAFE mode will not provide strong consistency guarantees.> We've seen this in previous versions of CAS as well, but could never determine what the CP Subsystem was nor what if anything to do with this. ** WARN [org.springframework.boot.autoconfigure.security.servlet.UserDetailsServiceAutoConfiguration] - < Using generated security password: **---- This generated password is for development use only. Your security configuration must be updated before running your application in production. > Not sure where to find documentation for this or what property is relevant And finally, we have a bunch or these: ** WARN [org.springframework.security.config.annotation.web.builders.WebSecurity] - ** WARN [org.springframework.security.config.annotation.web.builders.WebSecurity] - ** WARN [org.springframework.security.config.annotation.web.builders.WebSecurity] - ** WARN [org.springframework.security.config.annotation.web.builders.WebSecurity] - ** WARN [org.springframework.security.config.annotation.web.builders.WebSecurity] - ** WARN [org.springframework.security.config.annotation.web.builders.WebSecurity] - ** WARN [org.springframework.security.config.annotation.web.builders.WebSecurity] - ** WARN [org.springframework.security.config.annotation.web.builders.WebSecurity] - ** WARN [org.springframework.security.config.annotation.web.builders.WebSecurity] - ** WARN [org.springframework.security.config.annotation.web.builders.WebSecurity] - ** WARN [org.springframework.security.config.annotation.web.builders.WebSecurity] - ** WARN [org.springframework.security.config.annotation.web.builders.WebSecurity] - ** WARN [org.springframework.security.config.annotation.web.builders.WebSecurity] - ** WARN [org.springframework.security.config.annotation.web.builders.WebSecurity] - ** WARN [org.springframework.security.config.annotation.web.builders.WebSecurity] - ** WARN [org.springframework.security.config.annotation.web.builders.WebSecurity] - ** WARN [org.springframework.security.config.annotation.web.builders.WebSecurity] - ** WARN [org.springframework.security.config.annotation.web.builders.WebSecurity] - ** WARN [org.springframework.security.config.annotation.web.builders.WebSecurity] - ** WARN [org.springframework.security.config.annotation.web.builders.WebSecurity] - -- Baron Fujimoto ::: UH Information Technology Services minutas cantorum, minutas balorum, minutas carboratum descendus pantorum -- - 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/CAAjLUL1e6sRjAQfyP9uDdCCacknwGx4ouiUtgwLhm5k_nJvA1A%40mail.gmail.com.
[cas-user] Re: JDBC attribute repository sql search by principal
Digging thru code:
SimpleUsernameAttributeProvider.java, method getUsernameAttributeValues,
there is this line:
if (query.containsKey(this.usernameAttribute)) { ...}
I see I can perhaps override the username with a userNameAttribute. I have
not found any config where I can define this value.
Anyone know what property controls this?
-psv
On Wednesday, July 19, 2023 at 3:58:01 PM UTC-5 Pablo Vidaurri wrote:
> Config info:
>
> cas.authn.attribute-repository.jdbc[0].sql=select a, b, c from user_table
> where {0}
> cas.authn.attributeRepository.jdbc[0].username=USER_ID
> cas.authn.ldap[0].principalAttributeId: uid <-- uid is jsmith but login
> user name at UI is john@foobar.com
>
> Looks like principle (uid) is not being used and instead the username from
> credentials. *Is this a bug?*
>
> Log info:
>
> 2023-07-19 13:22:08,418 DEBUG
> [org.apereo.services.persondir.support.jdbc.SingleRowJdbcPersonAttributeDao]
> - builder 'null'>
>
> 2023-07-19 13:22:08,429 DEBUG
> [org.apereo.services.persondir.support.jdbc.SingleRowJdbcPersonAttributeDao]
> - from query Map {principal=[jsmith], Email=[john@foobar.com],
> firstName=[John], GivenName=[John], lastName=[Smith],
> credentialClass=[UsernamePasswordCredential], credentialId=[
> john@foobar.com], username=[john@foobar.com]}.>
>
> 2023-07-19 13:22:08,430 DEBUG
> [org.apereo.services.persondir.support.jdbc.SingleRowJdbcPersonAttributeDao]
> - john@foobar.com]>
>
> 2023-07-19 13:22:09,818 DEBUG
> [org.apereo.services.persondir.support.jdbc.SingleRowJdbcPersonAttributeDao]
> - john@foobar.com] and got results []>
>
> On Friday, July 14, 2023 at 5:10:14 AM UTC-5 Pablo Vidaurri wrote:
>
>> I have a single row lookup, so i have in my config:
>> cas.authn.attribute-repository.jdbc[0].sql=select * from user_table where
>> {0}
>> cas.authn.attributeRepository.jdbc[0].username=USER_ID
>>
>> This seems to search by the user id entered at the login page. But I'd
>> like to use the value from the resolved principle provided by LDAP:
>>
>> cas.authn.ldap[0].principalAttributeId: uid
>>
>> So user logs in with jsmith88 and ldap resolves the principle to be
>> j.s...@example.com.
>> I'd like to use the principle value to look up jdbc userAttributes.
>>
>> Any way to configure CAS to do that?
>>
>>
>>
--
- 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/20f7ec99-6575-4148-809b-f93695c96e4fn%40apereo.org.
Re: [cas-user] Simple MFA to Surrogate bypasses surrogate selection
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
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)
>>>
>>>
[cas-user] JCaptcha
Hi there, Is there any possibility to integrate JCaptcha in CAS 6/7 as it could be done in CAS 3/4? Such as: https://apereo.atlassian.net/wiki/spaces/CAS4UM/pages/102957015/JCaptcha Thanks, Diego -- - 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/7f441088-5f71-4c70-bee6-aef42035cb88n%40apereo.org.
[cas-user] Re: hCaptcha integration
I forgot the version: CAS 6.6.8 El miércoles, 26 de julio de 2023 a las 10:47:49 UTC-3, Diego Dave escribió: > Hi there, > > When I configure captcha integration with hCaptcha, the captcha works but > not validate after clicking the login button. > > This is my setup in application.yml file: > > cas.google-recaptcha.enabled: true > cas.google-recaptcha.version: HCAPTCHA > cas.google-recaptcha.verifyUrl: https://api.hcaptcha.com/siteverify > cas.google-recaptcha.siteKey: ... > cas.google-recaptcha.secret: ... > > Also I try the verifyUrl: https://hcaptcha.com/siteverify with same > effect. > > The integration with reCaptcha works properly with this conf: > > cas.google-recaptcha.enabled: true > cas.google-recaptcha.version: GOOGLE_RECAPTCHA_V2 > cas.google-recaptcha.verifyUrl: > https://www.google.com/recaptcha/api/siteverify > cas.google-recaptcha.siteKey: ... > cas.google-recaptcha.secret: ... > > -- - 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/3c64fb3c-5742-49a2-9a3b-912d42d62e62n%40apereo.org.
[cas-user] hCaptcha integration
Hi there, When I configure captcha integration with hCaptcha, the captcha works but not validate after clicking the login button. This is my setup in application.yml file: cas.google-recaptcha.enabled: true cas.google-recaptcha.version: HCAPTCHA cas.google-recaptcha.verifyUrl: https://api.hcaptcha.com/siteverify cas.google-recaptcha.siteKey: ... cas.google-recaptcha.secret: ... Also I try the verifyUrl: https://hcaptcha.com/siteverify with same effect. The integration with reCaptcha works properly with this conf: cas.google-recaptcha.enabled: true cas.google-recaptcha.version: GOOGLE_RECAPTCHA_V2 cas.google-recaptcha.verifyUrl: https://www.google.com/recaptcha/api/siteverify cas.google-recaptcha.siteKey: ... cas.google-recaptcha.secret: ... -- - 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/ef32b82b-90ea-4e8f-a422-5d5a8a138a13n%40apereo.org.
