Consolidate the id stored against the Saml2 user to avoid duplicates #102
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
At the beggining of the indentify process, a NameId is extracted from the payload that the Saml2 backend sends, and that is set on
environ['REMOTE_USER']
by repoze.who:https://github.com/DataShades/ckanext-saml2/blob/91ccffd3ec96d76d9f3b4fdc59d6140a0c04ef8e/ckanext/saml2/plugin.py#L295:L298
In my case this payload was:
So the NameId extracted was
amercader@rockfound.org
.This NameId is immediately used to check if a Saml2 user with the same name id exists in the database.
The problem is that when creating a new instance of a Saml2User, the extension is using a different id:
ckanext-saml2/ckanext/saml2/plugin.py
Line 429 in 91ccffd
This
saml_info
comes fromenviron["repoze.who.identity"]["user"]
and in my caseenviron["repoze.who.identity"]["user"]["id"]
(what is used when creating the newSAML2User
) was justamercader
.This meant that every time I tried to log in, the extension couldn't find any existing user with NameId
amercader@rockfound.org
, so it tried to create a new one (and failed because of the SAML2User.name_id unique constraint).This patch ensures that the same key that is used to check if a user exists is the one that is actually stored.
I assume that in most scenarios these two ids are the same and that's why this hasn't been an issue so far.