specify / specify7

Specify 7
https://www.specifysoftware.org/products/specify-7/
GNU General Public License v2.0
66 stars 36 forks source link

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

Open mpitblado opened 1 month ago

mpitblado commented 1 month ago

Describe the bug A user is successfully able to setup and link a Specify account 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:

Reported By Beaty Biodiversity Museum

Additional context

mpitblado commented 1 month ago

All other users in Division 2 (following the example above) had their invite link for SSO created while the admin user was also in Division 2. No further problems were encountered across 8 additional users.

As it doesn't make sense to intentionally try to replicate this bug for another real user, closing the issue. If a future user experiences this issue, the above solution is not proven as causal, but would likely be a good first thing to try. If able, you can rescue a user that experiences the bug by giving them read-only access to the collection they are erroneously being redirected to.

mpitblado commented 1 month ago

Unintentionally reproduced this error with a second user, also in Division 2. The user was also redirected to collection id 4, so perhaps there is a reason why that collection is being selected specifically.

specifysoftware commented 3 days ago

This issue has been mentioned on Specify Community Forum. There might be relevant details there:

https://discourse.specifysoftware.org/t/problems-with-login-over-entraid-regarding-rights/2146/4

funkyferdy commented 5 hours ago

For me its a bug in SSO part - Just a sidenote: if SAME user id logs in locally (you generate him a password) and let him login localy and not SSO - the system work as expected.