-
Notifications
You must be signed in to change notification settings - Fork 520
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
OpenID: Integrate permissions (Fixes #2523) #2769
Conversation
* Ability to set group * Ability to set more advanced permissions * Modified TextInputWithLabel to provide an ability to specify a different placeholder then the name
Also removed some semicolons
In testing I came across an issue where I set the root user type to admin. We need to make sure the root user type cannot be changed |
Only disallow when email_verified explicitly false Also check username besides preferred_username, even when its not included in OIDC checks (synology uses username)
I tested this on my instance and it fixed the SSO Error i had with Synology for me. Tested it on 3 users, all of them working now. |
…hanges - Update permissions example to use UUIDv4 strings for allowedLibraries - More validation on advanced permission JSON to ensure arrays are array of strings - Only set allowedTags and allowedLibraries if the corresponding access all permission is false
I did a lot more testing and it is working great for me. I updated the advanced permission check so it will only perform an update to the DB if changes were actually made. It will also only log that is updating the group/permissions if an update is required. I added more validation to the permission check so we ensure the arrays are valid. The The example permissions getting shown now show a UUIDv4 for the allowedLibraries so users don't try putting the library name there. Thanks! |
Integrate full permission support.
The user can configure (all optional and independent):
If not configured, will like before simply assign "user"
If the whole claim (if configured) is missing, login will be denied. If a parameter like
canDownload
is missing, it will be treated asfalse
. If a unknown parameter is provided, login will be denied. If user is an admin, it will be ignored.Can be tested with Authentik like this:
Here is an example expression, which adds the "admin" group if the user is in the "Dev" authentik group:
For the advanced permissions, do the same and name the scope something like "abspermissions".
Note that here (in python?) the booleans must be upper case.
Also make sure that after saving you click on "Test" beside the mapping and select a test user. It should show for the first mapping the correct groups including for example user or admin. For the second the claim.
Then go to Providers -> Select your ABS provider -> Edit -> Advanced Protocol Settings. And select additionally your new mappings.
I tested it extensively but make sure to also do some tests.
Also whats a bit weird in code I noticed, we use:
around line 83. But at other places
Not sure if this has a specific purpose but we should probably make it consistent, esp. as the first S has different case but means the same variable.