Problems with Login over EntraID regarding rights

dfernandez · November 28, 2024, 12:40pm

Hello! So, we have the following issue. We have configured SSO with entra ID and everything is working as expected (so far). For now it was tested only with users with administration rights (to all collections). But now we are working on “real” users with limited rights to an collections and i “got stuck”.

To replicate the issue i have done following:

Create an user that has Limited Access to an Collection → OK
Invite the user via Invite-Link → OK
At this Point the user clicks on the invite link (in a Private windows just to be sure), does his authentication, comes back to specify, is logged in and has access to the stuff that he needs to see. → OK

It looks like this:

Now comes “the bug” Part: User closes Browser. User Open a Browser (again in a Private window) user opens specify in Browser, clicks on Login with OICD (or whatever that button is named), makes authentication in EntraID, will be redirected back to specify after succesfull auth and does NOT see what he should see. I Would expect the same specify as first time. Instead he gets a json output with an error. This looks like this:

So, my first idea is that some rights are screwed or something so i doublecked everything but looks fine. So i set a password to this user to be able to login localy instead with External Identity Provider. So again, loged in “localy” and Bam, everything is working like it should.

If i give the User rights to the collection 4 (see second screenshot) then its working also with OIDC, BUT, he should not be able to do stuff in Collection “4”. He has no rights for it. So i “assume” he goes for collection 4 because its the first collection in database or something like this? All other collections have higher IDs.

So, i think i found a bug or is there any setting regarding this behavior?

Heryk · November 28, 2024, 1:46pm

Hi @dfernandez,
Just to confirm,
Could you check if there are any duplicate user entries in the “spuserexternalid” database table?
See this post for more info: SSO Authentication Issue with Duplicate User Entries in spuserexternalid Table - Get Help - Specify Community Forum

dfernandez · November 28, 2024, 3:30pm

Yes, there are none, this happens if the user clicks more than once on the invitation link, i allready know this behavior, but is not the case here. There is only one with the right specifyuser_id and it matches with the id in the table specifyuser.

I just wondering where the collectionid = 4 is coming in my case.

markp · November 28, 2024, 5:19pm

This is the same bug we had! Even collectionid 4 is the same! Thought it was such a weird fluke that I decided to close it, but I was also able to replicate across 2 users.

github.com/specify/specify7

NoMatchingRuleException: SSO redirects user to collection id that they do not have access to

opened 04:50PM - 10 Oct 24 UTC

closed 04:49PM - 21 Oct 24 UTC

mpitblado

1 - Bug

**Describe the bug** A user is successfully able to setup and link a Specify ac…count with an identity broker, and *complete a successful sign in through SSO once*. The next time they go to sign in (on a different machine), they receive the following error. `{"NoMatchingRuleException": [{"collectionid": 4, "userid": 8, "resource": "/system/sp7/collection", "action": "access"}]}` Interpreting the error seems straightforward, `userid 8` is trying to access `collectionid 4`, which they do not have access to. The question is why SSO is directing them there in the first place. SSO should return a user to the same collection they left off at (because the session is still active application side), but they never would have been able to have access to this collection, and thus could not previously have been in it. ``` Division 1: [Collection] [Collection] [Collection] <- collection id 4 ... Division 2: [Collection] <- user id 8 has access here, and only here ``` When the user *is* given read-only access to `collectionid 4` SSO works just fine, confirming the above interpretation. Note that through this process #2405 comes into play, but I will keep those details out of this report and see if they have been documented there. **To Reproduce** My hunch is that this error is related to #2405, as all other users have worked fine except for this user, which is the only one in a separate division. At this point, I am not certain on how to reproduce this, and am opening this issue because we have the opportunity to narrow down what can be causing this (as we have several users left who haven't been setup yet in that division). The first thing that I will pay attention to for the next user, is whether the collection/division that the admin is in when creating the invite link matters. Perhaps if the admin is in division 1, while creating a link for a user in division 2, then the wires get crossed. I do not have a hypothesis for why their first SSO sign-in worked the first time for them, before they were given read-only access to `collectionid 4`. I do not know why SSO routed to `collectionid 4` specifically out of the other available options. **Expected behavior** The user is able to sign in through SSO and will always be placed into the one collection that they have access to (if that is the case), regardless of division. **Screenshots** N/A. Error message appears as black text on blank web browser window. **Crash Report** N/A Please, also fill out the following information manually: - Specify 7 Version: 7.9.6.2 - Database Name: beaty **Reported By** Beaty Biodiversity Museum **Additional context**

markp · November 28, 2024, 6:08pm

I wonder if it is these lines that are causing it. @dfernandez, in your situation, does the user only have access to one other collection?

github.com

specify/specify7/blob/da4f46f35666aca6b9640b1b72f964976ce1ac97/specifyweb/accounts/views.py#L371C1-L373C29


      
          if len(available_collections) == 1:
              set_collection_cookie(redirect_resp, available_collections[0].id)
              return redirect_resp

dfernandez · December 2, 2024, 7:41am

Hello @markp !

Yes! We have 4-5 Collections and the user is only allowed to exactly 1 Collection. We don’t use divisions at all. But its same behavior you described in the github issue.

dfernandez · December 2, 2024, 7:45am

Blockquote
I wonder if it is these lines that are causing it.

available_collections[0].id

Maybe system should check the first avaiable collection for the given user? Im really not a programmer but my first avaiable collection IS 4 just not for the given user

markp · December 2, 2024, 6:40pm

Thank you for this, this provides evidence that it is not related to Cannot set batch of agents for collection access · Issue #2405 · specify/specify7 · GitHub. Based on the only agents we had encountered the error with being in the one isolated division, I thought this was related, but it appears not to be.

I guess this brings about two questions:

What is it about the users that it is occurring with that are different than others? We have had other users that only have access to one collection be able to login through SSO just fine, so I don’t think it is the indexing ([0]) or the condition being the issue then.
I’ll have to ask our two users who have experienced the error, but presumably if I were to revoke their read-only access to collectionid 4, they would be able to login? Maybe I’ll work with them today to see about that

dfernandez · December 3, 2024, 7:52am

I would also ask: Why its working the first time sending an invititation link perfectly but not a second time when user does actually a login with sso. And why it is working perfectly when same userrecord is logged in with a local password. Specify has all needed information but it looks like in “SSO Login” case is not “initialised” right.

Maybe some parameter missing in callbackurl or something? Just a idea.

Another idea: When i log in “localy”, there is a screen where i need to select the collection. This specific screen is not showing up when i do SSO login. On this screen i need to select my collection “accounts/choose_collection/?next=”

This is the notable difference in the 2 ways of login.

markp · December 3, 2024, 6:56pm

So I worked with one of the two users this morning, once given, the read-only access to collectionid 4 can then be revoked, and they are able to login fine through SSO. So as a workaround if this user really needed to get setup, and if its possible in the constraints of your access model, the read-only access could be given and then immediately revoked as soon as they switch back to their normal collection via the collection picking in the nav. They just need to be able to complete that route once. As I just did it this morning, time will tell if any session or cookie expiring messes things up, but I think it should be fine for them from here on out.

Your idea about the parameter seems plausible, I’ll look at the code some more today and see if I can spot anything. After working with the user above, it further supports that this bug will only present itself the second time a user logs in (with the first being the login immediately after setup). After the second time, they will end up going to the one collection they have access to just fine, which is what enables the permission to collectionid 4 to be revoked.

Topic		Replies	Views
SSO Authentication Issue with Duplicate User Entries in spuserexternalid Table Get Help	1	25	October 31, 2024
Login with EntraID (Azure) Get Help	29	602	October 4, 2024
Confusing management of user access to collections Get Help	11	358	February 23, 2023
Greyed-Out User Invite Link in Specify-7 Get Help	2	25	October 10, 2024
Specify7 Login error for one user Get Help	27	470	February 29, 2024

Problems with Login over EntraID regarding rights

Related topics