Wrong user authenticated

297 views
Skip to first unread message

Danilo Mendes

unread,
Oct 6, 2020, 10:06:20 AM10/6/20
to CAS Community
Hello,

I have a 6.1.7.1 installation authenticating gsuite apps against a LDAP directory. It`s configured using standalone profile.

Most of the time it works OK, but sometimes when two users tries to authenticate at the same time it sends wrong responses and User A opens User B account.

Can you o help me debugging? Or to point a direction I can follow? 

Thank you.


Danilo Mendes

unread,
Oct 8, 2020, 1:59:28 PM10/8/20
to cas-...@apereo.org
My server is hosted on a vmware4 server and I`ve followed a lead about entropy and noted that /dev/random dont play well with VMs.

Do any of you think it could be related? 

--
Danilo Mendes


--
- 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/c03472f2-56d5-4357-9af6-94f4f045728fn%40apereo.org.

Richard Frovarp

unread,
Oct 8, 2020, 2:03:36 PM10/8/20
to cas-...@apereo.org
Probably not? That sounds like code that is being hit somewhere that isn't thread safe. The built in LDAP code to CAS should be just fine with that respect. Assuming you're using a well supported LDAP server that wouldn't have thread issues? I don't know how a HTTP proxy would impact this. I guess the question is, do you have any custom code anywhere in the network or login flow?

Duncan Brannen

unread,
Oct 9, 2020, 7:33:35 AM10/9/20
to cas-...@apereo.org

 

There’s not a caching proxy in front of your application is there? If so make sure caching is switched off, we’ve seen something similar and the cache was the problem.

 

Duncan

 

From: 'Richard Frovarp' via CAS Community <cas-...@apereo.org>
Sent: 08 October 2020 19:04
To: cas-...@apereo.org
Subject: Re: [cas-user] Wrong user authenticated

 

Probably not? That sounds like code that is being hit somewhere that isn't thread safe. The built in LDAP code to CAS should be just fine with that respect. Assuming you're using a well supported LDAP server that wouldn't have thread issues? I don't know how a HTTP proxy would impact this. I guess the question is, do you have any custom code anywhere in the network or login flow?

 

On Thu, 2020-10-08 at 14:59 -0300, Danilo Mendes wrote:

My server is hosted on a vmware4 server and I`ve followed a lead about entropy and noted that /dev/random dont play well with VMs.

 

Do any of you think it could be related? 


--

Danilo Mendes

 

 

On Tue, Oct 6, 2020 at 11:06 AM Danilo Mendes <djme...@gmail.com> wrote:

Hello,

 

I have a 6.1.7.1 installation authenticating gsuite apps against a LDAP directory. It`s configured using standalone profile.

 

Most of the time it works OK, but sometimes when two users tries to authenticate at the same time it sends wrong responses and User A opens User B account.

 

Can you o help me debugging? Or to point a direction I can follow? 

 

Thank you.

 

 


---
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.

--
- Website: MailScanner has detected a possible fraud attempt from "eur01.safelinks.protection.outlook.com" claiming to be https://apereo.github.io/cas
- Gitter Chatroom: MailScanner has detected a possible fraud attempt from "eur01.safelinks.protection.outlook.com" claiming to be https://gitter.im/apereo/cas
- List Guidelines: MailScanner has detected a possible fraud attempt from "eur01.safelinks.protection.outlook.com" claiming to be https://goo.gl/1VRrw7
- Contributions: MailScanner has detected a possible fraud attempt from "eur01.safelinks.protection.outlook.com" claiming to be 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.

Danilo Mendes

unread,
Oct 9, 2020, 8:53:42 AM10/9/20
to CAS Community, d...@st-andrews.ac.uk
Thank you for your responses. 

It only customized the login form adding some warnings about usage.

It doesnt have a proxy, or cache... At the beginning we had a load balancer (haproxy) serving a CAS cluster, but, mitigating this issue, I removed it for simplifying the installation and because it has an open issue that I thought it might be related (https://github.com/haproxy/haproxy/issues/583). Since then I have only one CAS working directly and the problem persists.

After Richard's reply I extended my investigation to the LDAP server and found that the node I was using was very old and unmaintained 389-ds. Then I switched the config to a new one.

Since that I have few hours without incidents. I hope it keeps like that.

Danilo Mendes

unread,
Oct 13, 2020, 1:51:02 PM10/13/20
to CAS Community, Danilo Mendes
That didn't solve it.

But I found one customization: one line groovy script for fixing the username for google.

I replaced it by another attribute provider.

Samuel Lyons

unread,
Oct 15, 2020, 5:38:41 PM10/15/20
to CAS Community, djme...@gmail.com
We have solved an issue very similar to this and is probably this issue. What happens is that there's a default attribute repository cache that basically stores the username's hashCode  (the username is in like a list with one value or something like that and then it calls the hashCode() method on it)   as a key  https://github.com/apereo/person-directory/blob/2e1439bf804a2b93019b8e5846837fe2628abbd7/person-directory-impl/src/main/java/org/apereo/services/persondir/support/AttributeBasedCacheKeyGenerator.java#L326 .  The method .hashCode does NOT guarantee unique values out of it. In fact similar string have a higher probability of having the same hashCode but this still can effect ones that are fairly different. To know if this is your issue, take the username of both inidividuals and run a test java program that calls the default .hashCode method on them and see if they have the same value. The solution that was found was to turn the cache off

cas.authn.attribute-repository.expiration-time=0
cas.authn.attribute-repository.expiration-time-unit=MINUTES

Samuel Lyons

unread,
Oct 15, 2020, 5:42:54 PM10/15/20
to CAS Community, Samuel Lyons, djme...@gmail.com
err sorry, for 6.1 the attributes are

cas.authn.attributeRepository.expirationTime=0
cas.authn.attributeRepository.expirationTimeUnit=MINUTES

Danilo Mendes

unread,
Oct 23, 2020, 3:28:38 PM10/23/20
to Samuel Lyons, CAS Community
Thanks for your insight! I will look into it.

But I think my issue was "org.apereo.cas.services.GroovyRegisteredServiceUsernameProvider". Since I replaced it, CAS authenticated 150k requests and no incidents reported so far.

Digging logs further I found that there is a property in the SAML response named "InResponseTo". At first I thought it should be unique, then I found other responses with the same InResponseTo. Some of them belong to responses to the same user, but a few to other users. The identified incidents have the same "InResponseTo" for different users and happened at the same second.

--
Danilo Mendes

Ganesh and Sashi Prasad

unread,
Oct 29, 2020, 1:15:00 AM10/29/20
to cas-...@apereo.org
Hi,

I have once got this error too. User A logged in and saw User B's profile. They were of different organisations, but both were using delegated authentication using pac4j and their own Identity Providers. This problem has never been seen when users use local LDAP.

I followed the suggestion here to test those two user names for similar hashcodes. The two user names share 5 consecutive characters and are therefore similar, but the hashcodes are not the same.

I am pretty sure the confusion occurred because of this kind of error (user names were very similar), but it's probably not the hashcode itself. It could be a related problem, though.

Can you please think of something else that could be causing this? It has happened only when we use pac4j, not otherwise.

Regards,
Ganesh

--
- 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/cb4031db-161d-4fe8-b5bb-67185018c1ben%40apereo.org.
Reply all
Reply to author
Forward
0 new messages