CAS 7.0.3: missing LDAP principal attributes when using DUO MFA

271 skatījums
Pāriet uz pirmo nelasīto ziņojumu

Mike S

nelasīta,
2024. gada 11. apr. 01:11:0311. apr.
uz CAS Community
(Apologies for the repost. The CAS version has been added in the subject line as well as the cas.properties file)

We are testing a CAS 7.0.3 POC system using universal prompt DUO MFA. The system is configured to use OpenLDAP for authentication. However, once DUO MFA is enabled via the Fawnoos blog entry, the attributes returned for the principal are from DUO.

How do we tell CAS to only use the LDAP attribute repository?

Thanks,
Mike

cas.properties

cas.server.name=https://cas-poc.xxx.yyy
cas.server.prefix=${cas.server.name}/cas
cas.server.scope=xxx.yyy
cas.host.name=xxx.yyy

logging.config: file:/etc/cas/config/log4j2.xml
logging.level.org.apereoi.cas=debug

server.port=8443
server.ssl.enabled=true
server.ssl.protocol=TLS
server.ssl.key-store=file:/etc/cas/config/keystore.jks
server.ssl.key-store-password=XXXXXXXXXXXXXXXXXXX
server.ssl.key-password=YYYYYYYYYYYYYYYYY
server.ssl.key-store-type=JKS
server.ssl.key-alias=default

server.servlet.context-path=/cas
server.servlet.application-display-name=cas

cas.server.tomcat.http[0].enabled=false
cas.server.tomcat.http-proxy.enabled=true
cas.server.tomcat.http-proxy.secure=false
cas.server.tomcat.http-proxy.scheme=https
cas.server.tomcat.http-proxy.protocol=HTTP/2
server.tomcat.remoteip.internal-proxies=AAA.BBB.CCC.DDD
server.tomcat.accesslog.request-attributes-enabled=true
server.tomcat.max-http-form-post-size=2097152
server.tomcat.max-threads=200

[service registry config omitted]

cas.authn.accept.users=
cas.authn.accept.enabled=false

cas.authn.ldap[0].type=AUTHENTICATED
cas.authn.ldap[0].ldap-url=ldaps://ldap1.xxx.yyy,ldaps://ldap2.xxx.yyy
cas.authn.ldap[0].base-dn=dc=xxx,dc=yyy
cas.authn.ldap[0].search-filter=(|(uid={user})(mailAddress={user}))
cas.authn.ldap[0].bind-dn=uid=ro-ldap-user,ou=users,dc=xxx,dc=yyy
cas.authn.ldap[0].bind-credential=XXXXXXXXXXXXXX
cas.authn.ldap[0].principal-attribute-list=altEmailaltEmailDate,authViaAltEmailVerificationKey,[...]

cas.authn.mfa.triggers.global.global-provider-id=mfa-duo
cas.authn.mfa.duo[0].account-status-enabled=true
cas.authn.mfa.duo[0].duo-secret-key=XXXXXXXXXXXXXXXXXXXXXXXXXX
cas.authn.mfa.duo[0].duo-integration-key=YYYYYYYYYYYYYYYYY
cas.authn.mfa.duo[0].duo-api-host=ZZZZZZZZZZZZZZZZZZZZZZ

Ray Bon

nelasīta,
2024. gada 12. apr. 10:54:4712. apr.
uz cas-...@apereo.org
Mike,

I can confirm this behaviour.
DefaultPrincipalElectionStrategy was changed between 6.5 and 7.0. The change was in 5bcef20 about 5 months ago.

The old behaviour was to select the first principle in a list; new behaviour defaults to last.
Even setting this property,

cas.person-directory.principal-resolution-conflict-strategy=first

does not work.

Printing the list of principals immediately before PrincipalElectionStrategyConflictResolver is invoked:

2024-04-11 23:40:23,144 ERROR [ org.aper.cas.auth.prin.DefaultPrincipalElectionStrategy] - <principal: SimplePrincipal(id=rbon, attributes={cn=[Ray Bon], description=[ROLE_ADMIN], domain=[uvic.ca], ...
2024-04-11 23:40:23,144 ERROR [ org.aper.cas.auth.prin.DefaultPrincipalElectionStrategy] - <principal: SimplePrincipal(id=rbon, attributes={duoAud=[...], duoAuthCtxAccessDeviceIp=[...], ...

The principal id's are the same (so merging attributes should work). 

Our setup fetches attributes after authentication (instead of at the time of authentication) but before duo flow.

I will investigate if there is an effect of when ldap attributes are retrieved; as well as look into other possible config settings that might affect attribute merging.

Ray


On Wed, 2024-04-10 at 12:47 -0700, Mike S wrote:
Notice: This message was sent from outside the University of Victoria email system. Please be cautious with links and sensitive information.

Mike S

nelasīta,
2024. gada 12. apr. 14:40:3012. apr.
uz CAS Community,Ray Bon
Thanks for your response Ray. I've been banging my head against this for a while and I thought it was something I was missing. I've verified the conflict resolver option doesn't work.

The log debug log output  shows the LDAP and DUO attributes at one point are merged, but the result is discarded.

Is there a suggested workaround?

Ray Bon

nelasīta,
2024. gada 13. apr. 00:18:0613. apr.
uz seym...@gmail.com,cas-...@apereo.org
Mike,

What logger did you enable to see this?

Ray

Łukasz Woźniak

nelasīta,
2024. gada 13. apr. 00:18:0613. apr.
uz cas-...@apereo.org,Ray Bon
Hi,

We are using CAS in version 6.5 on production with protocols OAuth, SAML, OIDC. We use attributeRepository from LDAP because we need memberOf with recursive data. There are many memberOf so we need to filter it out. We use attributeReleasePolicy with RegisteredServiceMutantRegexAttributeFilter. And on version 6.5 it works

We upgraded to version 7.0.3 and now resolving attributes is working very bad. In OAuth 2.0 protocol we get all values from memberOf without filtering. In SAML protocol it works good.

I've checked and ChainingAttributeReleasePolicy is returning good result. But like Mike S sad this values are merged (all attributes + that filtered out).



--
- 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+u...@apereo.org.
To view this discussion on the web visit https://groups.google.com/a/apereo.org/d/msgid/cas-user/b07dcb6c-4c61-4823-9822-1efb0ad53c78n%40apereo.org.

Mike S

nelasīta,
2024. gada 15. apr. 12:40:5415. apr.
uz CAS Community,Ray Bon,seym...@gmail.com
Hi Ray,

it was in /etc/cas/config/lob4j2.xml, setting the log level to debug:

<Configuration monitorInterval="5" packages="org.apereo.cas.logging">
    <Properties>
        <Property name="baseDir">/var/log/cas</Property>
        <Property name="cas.log.level">debug</Property>

Mike S

nelasīta,
2024. gada 15. apr. 17:04:3615. apr.
uz CAS Community,Mike S,Ray Bon
FYI, downgrading to 6.6.13 works. DUO universal prompt functions properly and the principal attributes are from LDAP only. I'm suspicious that something about DUO and/or MFA is broken in CAS 7.0.3.

Ray Bon

nelasīta,
2024. gada 16. apr. 19:25:3216. apr.
uz seym...@gmail.com,cas-...@apereo.org
I have been able to confirm that the presence of the surrogate log in feature can create the observed problem. 

implementation "org.apereo.cas:cas-server-support-surrogate-webflow"

The non merging of attributes happens even though no surrogate login takes place.

Ray

Mike S

nelasīta,
2024. gada 17. apr. 09:53:5517. apr.
uz CAS Community,Ray Bon,seym...@gmail.com
You're right! Removing support-surrogate-webflow allows merging to proceed properly. Think this will be addressed in 7.1, or is this working as intended and we have to do something else to enable proper attribute merging?

Ray Bon

nelasīta,
2024. gada 23. apr. 23:54:0323. apr.
uz seym...@gmail.com,cas-...@apereo.org
I created, https://github.com/apereo/cas/pull/6019 as a fix for this.

If you can not wait for the changes to be in mainstream cas, you can copy in the modified files to your overlay.

Ray

Robin Joseph

nelasīta,
2024. gada 5. maijs 23:30:425. maijs
uz cas-...@apereo.org
I have the same issue with 7.0.3 and Duo MFA, I am also hoping for a fix with 7.1, Thank you Ray and Mike.

--
- 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+u...@apereo.org.
Atbildēt visiem
Atbildēt autoram
Pārsūtīt
0 jauni ziņojumi