-
Notifications
You must be signed in to change notification settings - Fork 11k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
CAS connector function to merge with existing users #6655
Comments
That would require the CAS/LDAP/foobar/you-name-it plugin to make sure that the newly authenticated user is EXACTLY the same as already provided by another auth mechanism - in order to safely "merge" external service data. I do also see race conditions from multiple auth providers overriding attributes depending from what auth provider the user logs in from. |
Hi, Thank you for the feedback. The race condition would be a "theoretical" issue in case the same user logs in at EXACTLY the same time by two different auth methods leaving the user object in an inconsistent state. My request originated by dealing with other applications connected to SSO solutions. The SSO normally just tells the application that the current user is authenticated and who the user is (federation ID, principal ID, username). Regards, |
Hey, Just want to chime in here. There are a few use cases for this. For example, I use this as a chat server for my university (I am a tech officer here) and the CS department is making great use of RocketChat. I have started to use the server for course announcements, which sometimes means creating users before they have logged in, so that I can add them to a course via api. If I create a user, then they try use CAS to login, they get "user already exists". GitLab deals with this by having "providers" for each type of auth, and a user can add and remove providers. So in that API I create users with the CAS provider. So, either CAS username should not be considered the same as the RocketChat/LDAP username (i.e. add something similar to gitlab "providers"), or a suggestion would be to match and "merge" on a custom attributes. Let the admin decide. Otherwise if username is the only required attribute, then always merge on that and let the admin decide if and how other details should be overwritten... Default would be "don't merge anything". |
Okay so I saw you can add customFields in the RESTFul API. I was all excited and did a few tests. Unfortunately, it seems the custom fields argument is not what I wanted. Instead of adding the CAS to the services, it just ignores the input, creating a user with no cas. I then read some more of the docs and now understand why my custom fields expectation was unreasonable. So I guess then the next suggestion is to expand the API to include the CAS service? Also, I would be happy to share my API scripting if anyone wants it. It's in python. |
Hi, i have installed in my local machine a server RC and i have to sincronize user via CAS, but i am obbliged to leave the checkbox "Registration with Authentication Services" to true, because in your record user exist the services json for cas. "services": { For my purpose i create the user via rest api and next to access in rocket chat via CAS, but with the checkbox setting in true i have the error "User Exist...", it's possible to carry out an update to the record user with the services cas and check the first via CAS and the next via Password. It's presumibile resolve this issue in this mode? Thanks Best regards |
@domenicocosta I'm not sure if I understood exactly what you want to do. You want to manually update the users on the database with the CAS username, or are you looking for a way to have Rocket.Chat automatically detecting CAS users that were created through the REST API? |
Hi i have responce on chat openRocket thanks |
Here, users who authenticate via CAS also have the same LDAP user name. By doing some tests, I realized that if you authenticate first via CAS, you will be able to authenticate with the same user via LDAP, if it is not yet synchronized. The same does not happen in reverse. You can not authenticate via CAS if the user is already synchronized via LDAP. To solve the problem for now, I automated using the workaround below. For each user synchronized via LDAP, it will enter the necessary entries for authentication via CAS. crontab /usr/local/sbin/mergeCAS.js
|
This issue will be corrected in any milestone? |
The current version of Rocket.Chat already has this implemented (it was added two months ago), however, the next version will include a setting to disable it and it'll be disabled by default. I'll close this issue as the original problem has already been solved. |
Hello @pierre-lehnen-rc, |
A fix to the fix was added in the 3.4.2, it works very well now (Trust CAS Username). |
Rocket.Chat Version: 0.53.0
Running Instances: 1
DB Replicaset OpLog: Disabled
Node Version: 4.8.0
Hi, I am referring to #3379 as I do not think that the patch is fixing the underlying issue.
When it comes to authentication connectors they should not act exclusively.
E.g. we are using the LDAP connector to provide user and group information. This connector allows the option "Merge existing users", so that it is compatible with other connectors.
However the CAS does not allow that, so when the LDAP user is already existing and I want to login with CAS I am prompted with "user already exists" (Instead of just adding the CAS properties to the user object).
Usernames are unique, so whatever connector authenticates a user to be user XYZ rocketchat should allow this.
Would it be possible to include the "Merge" function of the LDAP module also to the CAS one?
Thank you and regards,
Christian
The text was updated successfully, but these errors were encountered: