-
Notifications
You must be signed in to change notification settings - Fork 115
Description
Hey there, it's me again!
I came up with this idea due to some discussion on our project regarding application specific user permission handling for new users.
Let me explain the motivation:
Background
- sso-server handles user management and user registration
- sso-client uses sso-server to check whether a requesting user is a valid, known sso-server user or not
- If a new user is registered on the sso-server, the sso-clients are unaware of this user, since they do not share the same database
- The new user data is stored on the sso-client on a first login. No local permissions (on the sso-client) could be configured beforehand, since this user was unknown to the sso-client
- The user might not have the required privileges and needs to contact the sso-client admin to get the permissions configured properly
Possible solution
There could be a /propagate
route on the sso-clients, which takes a request from the sso-server, checks it's authenticity and integrity and then populates the user table with the received data. This would be some kind of shortcut to the regular new-user-adding-on-client-routine, but not having the user logged in. It's only for having a new user written into the client's database before a first login. This gives the admins time to configure needed settings/permissions for this new user.
Discussion
@GaretJax
@FinalAngel
Are there any concerns from your side regarding this idea, before I start implementing and creating a PullRequest? Thanks for your replies in advance, guys!