I am currently trying to set up keycloak for a production scenario in which I have different contexts, each with users and admins. The admin should only be able to impersonate users from his context.
Giving an admin permission in the form of permissions to impersonate all users is not a problem. but how can I solve the above task? Can one of keycloak built in concepts (groups, roles, realms, scopes etc.) help me?
You have to enable --features=admin-fine-grained-authz and then.
Put your users into a group.
Create another user and grant this user "query-groups" and
"impersonation" roles (from the "realm-management" or "master-realm"
client, depending on the realm).
Go to your group, enable permissions, open "view" permission, and add a
user policy to allow the user to view a group, then repeat for "view-members" permission.
FInd more details here
and here
Related
I'm currently trying to find the best process for managing admin privileges throughout my PostgreSQL databases. What I am trying to do is assign permissions that are sufficient enough for in an admin role group where I can GRANT a user (another admin) to inherit the permissions of the role group; however, I'm not sure if this can be done or how to do this. The admin role group's privileges should be the following:
Able to add users
Able to view users and permissions in a database
Able to reset a user's password, dropping a user, or resetting a user's name
Able to show grants of a particular user
Able to add specific permissions for a user to a schema and table. (So have permissions to the database and tables)
For auditing purposes, should I even go with this approach of creating a role group or add a user (admin) with no role group? I remember reading that the role group would show as who did any changes rather than the specific user. Would appreciate clarification on this.
Thanks for reading my post.
I have two realms, a public webapp and an extranet where only employees can access.
I have tried setting group policies.
When I try to connect with an non-employee user, keycloak still returns the access token.
What did I miss?
EDIT.
I made a mistake, I only have 2 clients.
You have to limit the access granted to your access token to achieve this. There are three ways to do it (that I know of)
Audience: Allows listing the resource providers that should accept an access token.
Roles: Through controlling what roles a client has access to, it is
possible to control what roles an application can access on behalf
of the user.
Scope: In Keycloak, scopes are created through client scopes, and an
application can only have access to a specific list of scopes.
You can look at this example which explains the flow on how to achieve this using role based method. You can refer this as well.
I am new to AEM. I was going through the impersonating functionality in useradmin.
CQ documentation on impersonation
as per my understanding , impersonation can be done user to user. if there any way user can impersonate group i.e. if user-A can directly impersonate group-A with 5 user. As it would be really difficult for admin to impersonate every new user.
Please suggest
I'm developing a small database for a library but I'm completely ignorant when it comes to roles and privileges.
I've spent quite some time googling but I still don't truly get the mechanisms.
My aim is to create 3 basic roles:
User with no login (not really an user, just someone who wants to see the books the library has in store, but he can't do any action besides just watching)
User with login (He can preorder books and do other actions)
Admin (He can add new books, authors, genres and can give the admin privileges to other users)
At first I thought I could create these 3 roles specifying the various privileges each one has and then, on the related website, every time someone would connect he would have been considered an "User with no login" until the login which would've determinated whether he is an Admin or not; reading the PostgreSQL documentation I understood it's nothing like this, or perhaps I got it wrong.
I really have no clue what to do, any help would be appreciated.
What you want to do is reasonable. Your webapp should log in with its connection pool as a user (say mywebapp) that is marked NOINHERIT and has no rights except to SET ROLE to three other roles. Each of those roles describes one of the categories of users you mention above. You'll also need to GRANT the rights to access any tables used to look up and authenticate users to the mywebapp user.
When servicing a request, if it's acting on behalf of an anonymous user it does SET ROLE anonymous_web_user; or whatever.
If it's acting as a named user, it does SET ROLE authenticated_user;. You'd GRANT the right to read the table you use for authenticating users to the mywebapp role so it can authenticate them in whatever way your app does so.
If it's acting as an admin, it does SET ROLE admin;. Or, if there aren't many admins and they need different rights, you can make them PostgreSQL users, and SET ROLE the_admin_user_name;. Again, your app would pre-authenticate them, and SET ROLE if it was satisfied with the user's authentication.
When a connection is returned to the pool it is vital that the pool run the query DISCARD ALL; to clear the connection's role setting.
So, for example, you might:
CREATE ROLE mywebapp WITH LOGIN NOINHERIT;
CREATE ROLE anonymous_web_user;
CREATE ROLE authenticated_user;
CREATE ROLE admin_user;
-- 'mywebapp' can become anyone, but by default doesn't
-- get the rights of any of them since it's marked NOINHERIT
GRANT admin_user TO mywebapp;
GRANT anonymous_web_user TO mywebapp;
GRANT authenticated_user TO mywebapp;
-- All admins are authenticated users, since authenticated_user
-- is INHERITable
GRANT authenticated_user TO admin_user;
-- All authenticated users have the rights of anon users too
GRANT anonymous_web_user TO authenticated_user;
-- The app must be able to look up users
GRANT SELECT ON some_users_table TO mywebapp;
-- but only admins can change them
GRANT ALL ON some_users_table TO admin_user;
...
See Role membership.
We are a service provider. Suppose in our application, we originally have our own user/role management. Different users with different roles are allowed to use different features. So that when a user login we need to know which roles this user has, and prepare appropriate UI. We have administrator role, users with this role can assign roles to other users.
We are thinking of enabling SAML SSO for our application, now the problem is how do we setup roles for each user.
Solution 1, we relies on IdP to provide role information for each login user, the role information may come along with Assertion, but this may not work for all the IdPs.
Solution 2, we only retrieve user from the IdP, and manage the roles in our own application. For example, when we get an Assertion, we retrieve the username(or email address), and match with a record in our DB, if it doesn't exist we automatically create one for this new user. Then we rely on users with administrator role to assign correct role for this new user.
Now the questions is where is the first administrator coming from? Our customer gets our application, and turns on SAML SSO, now there is no users in the DB yet, then how can we resolve such bootstrapping issue? Is there any kinds of standard way? We have come up with different options but not sure which is better and what are the concerns for each options.
Option 1, have a default built-in administrator user. There is a regular native login page that built-in users can login without going through IdP(there is an option to turn it on/off if SAML SSO is enabled)
Option 2, during SAML SSO setup, ask for the administrator user name, so that we automatically create this user in our DB with administrator role. Then when this user login through IdP we could match him in our DB.
What are the other options?
For your first question about who should handle the roles. As I understand every customer has your One of your service provider software. And it connects to a central IDP that you own. If this is the case, it feels like its to complex letting the administrators handle roles on your IDP. I would go for number two.
About question number two. I have been in the same situation I can not remember that I have seen a obvious standard solution for this.
What we did was option 2. It works fine but it adds some complexity to the install procedure. We choose it because we would not have a native login page.
I thing maybe I would be better to go with option 1.
You can get the roles from the different directories of your IDP using your authorization layer. It removes the constraints on SAML and gives the same results as your solution 1.