You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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!
The text was updated successfully, but these errors were encountered:
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
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!
The text was updated successfully, but these errors were encountered: