I'm using the intranet workflow to manage a site and I've created folders that are "internally published". One of our users has the owner role even though they are a member.
When I visit {mysite}/myfolder/the_item/manage_reportUserPermissions?user={USERID}
their roles in the context of a private object are reported as:
Authenticated
Member
*Owner*
Reader
The Owner role is concerning here and I need guidance on how to troubleshoot this issue, I'm not sure why this users is inheriting or acquiring this role.
Other users with the Member role are fine, meaning they have the the following roles in the same context mentioned above:
Authenticated
Member
Reader
Assumingly from what you describe, the user has created the item.
As default behaviour creators are set to be the owner of an item.
If the assumption is right, you have nothing to worry about.
Related
In ASP.NET Boilerplate, why does it has roles and permissions to control authorization? Which is the difference between both?
Role: a group of permissions.
1. Why does ABP have roles and permissions to control authorization? What is the difference between the two?
Having both roles and permissions allows flexibility and ease for admins to control authorization.
The difference is that authorization only depends on permissions, not roles.
From https://aspnetboilerplate.com/Pages/Documents/Zero/Role-Management:
Roles are used to group permissions. When a user has a role, then he/she will have all the permissions of that role. A user can have multiple roles. The permissions of this user will be a merge of all the permissions of all assigned roles.
For example, a site moderator can be allowed to add, edit and delete any posts, including the ones written by others. A site moderator can add, edit and delete comments as well. If there are several site moderators, then a role can be easily assigned instead of individual permissions to each user.
2. Does a permission necessarily belong to a role? And does a role necessarily need permissions?
No, a permission can be assigned directly to a user.
No, a role does not need permissions. A role with no permissions is like a position (e.g. employee).
From https://aspnetboilerplate.com/Pages/Documents/Zero/Permission-Management:
Role Permissions
If we grant a permission to a role, all the users that have this role are authorized for the permission (unless explicitly prohibited for a specific user).
User Permissions
While the role-based permission management can be enough for most applications, we may need to control the permissions per user. When we define a permission setting for a user, it overrides the permission setting defined for the roles of the user.
In addition, there are also Organization Unit Roles (not documented yet). That is, a role can be assigned to an organization unit and users in that organization unit are considered to have that role.
I understand the usage of claims for things I would commonly refer to as "roles" or "permissions". I know that claims are more general, but from what I have seen in practice, it usually boils down to this: If user has this set of claims they can access certain areas, or perform certain functions.
Imagine a wiki application. You might have a content_contributor claim that would allow a user to add content, a content_admin claim that would allow a user to remove content, and a modify_user claim that would allow the granting of contributor rights to other user.
Taking this example a step farther, I may want to restrict users so that they can only see content created by themselves or their team.
If a user can only see content created by themselves, would we have a claim for each piece of content they created, or would we delegate that authorization to the application?
When you are talking about roles and permissions then you are talking about authorization.
Claims are typically not for authorization. (Identity)Claims are there to model the identity of the user: who is the user? The claims on itself do not tell anything about authorization. A user can have a role claim, but this doesn't tell the application what the user is allowed to do.
Authorization is done by the application, based on who the user is. Think of authorization as a set of rules, like:
18+: allow when user is older than 18 (DateOfBirth).
Use car: allow when user has a drivers license.
Or something like that.
Roles are a bit confusing, as they are often misused for authorization. Please read this article for some background information.
The problem with roles IMO is that these are not universal. I can be a Doctor in one hospital, while I'm a Patient in another. And I can be Admin for one tenant, but a User for another tenant. So they have only meaning within a certain context.
The only reason to include roles as claim is that you won't need to lookup this information as it is already present. But given the previous remark, you actually can't include this information. And it will only give you headaches when you do. Because you can't do simple things like update or change permissions or profile settings, until the user logs in again.
So as a rule of thumb: keep authorization close to the resource (api / website). Because that is the place where the business rules are implemented. And that's the place where you can store and update permissions, etc.
Keep a seperation of concerns when it comes to authentication and authorization. Authentication tells you who the user is, and authorization tells you what the user is allowed to do. Don't mix these two.
Translating this to your wiki application:
Create a seperate context where you store authorization information like roles and permissions. You can manage this in a central resource (for multiple applications) or use the context in your application. I would not mix this context with the business context.
Add a user in the authorization context and add a role content_contributor. Within the application read the permissions (from the central API, the local authorization context, a settings file, or anything that suits best) for that user (based on the sub claim). Cache it to speed up performance, and apply the rules to determine whether the user is allowed to access the resource.
You can extend this with resource-based authorization. Save the value of the sub claim in the content record to identify the owner. When the current user matches the sub claim value, then the current user is the owner.
You can use the same approach for teams. Add a teams table to the business context and link the user to one or more teams. Directly using the sub claim value or indirectly, using a Users table, also in the business context, where the user is linked to the sub claim value. You can add name, etc. in case you want to show this information (like in a report).
You can save team id and / or user id or sub claim value (owner is member of the same team as current user) in the content record in order to determine the allowed access for the user.
My setup would be like this:
Identity context: users + userclaims. For authentication only. Application independent.
Authorization context: users (id = sub claim) + per application: roles, permissions, etc. In seperate 'local' databases or in a central database. For authorization only.
Business context: users (Id, Name, 'foreign key' sub claim, without the actual database relation as the table is outside the context) + teams, profile, settings, etc. Linked to the sub claim value when users table is omitted.
In order to keep the users table in the business context up-to-date, periodically refresh the values. You can for instance update values when the user logs in after x time. Or once in a while query the Identity Context (using the API) to request user information (using the identities User Info endpoint).
In all contexts there can be a users table, but they all have a different meaning and contain other information. So there is no redundant information.
Authorization takes place inside the application and is based on the business rules (policies) and authorization information from the authorization context.
As a final remark, when the current system requires role claims (like for User.IsInRole() or [Authorize("role")]) then you can read (from cache) the role / permissions on each call and add these to the claims collection of the current user (claims transformation).
I am new to Keycloak and I try to use it as authentication server in my solution.
I have the following entity's model: the devices are owned by a particular company to which some users belong. User with role admin can grant permission for viewing some set of devices to a regular user but only those devices that belong to the admin's company. Thus all users except admins can view only a subset of all devices in company.
Based on these requirements, I decided to make companies as groups and devices as Keycloak's resources. To evaluate permissions, I chose rule based policy.
The question is -- Can I set group as an owner of resource to check this relation in policy?
If someone is more experienced in keycloak and knows how to better represent such model, please help.
Thank you in advance.
As working on keycloak, I didn't find any way to set the multiple owners for particular resources.
I'm having the alternate option to give the access permission, that owners have for their resources.
Let say Resource A owner is OWNER A, now there are two more user USER A and USER B. If suppose OWNER A already share the access permission to USER A and USER A wants to share Resource A to USER B on behalf of the Resource owner, then how should USER A can share the resource scopes to USER B?
Answer
Keycloak provides the facility of token exchanging or impersonation feature. With the help of this USER A can able to share the resources to USER B on behalf of the OWNER A (Owner of Resource A).
Reference: You just need to follow this Keycloak Impersonation
Add comments if you still face the problem
In Keycloak, you may represent a particular company (or any organization or organizational unit) as a realm:
https://www.keycloak.org/docs/latest/server_admin/index.html#core-concepts-and-terms
Create a new realm:
https://www.keycloak.org/docs/latest/server_admin/index.html#_create-realm
Then represent the company's users as users in the company's Keycloak realm
https://www.keycloak.org/docs/latest/server_admin/index.html#user-management
... and devices as Keycloak Clients (any kind of resource you want enforce permissions on is a Client in Keycloak model):
https://www.keycloak.org/docs/latest/server_admin/index.html#core-concepts-and-terms
An admin role is already defined by default for each role (Roles menu).
Instructions tested on Keycloak 4.0.0.
For each device, create the corresponding Client in Keycloak (Clients menu). Switch on Permissions Enabled on the Permissions tab of the new client. A list of admin console permissions will appear just below the switch button, such as the view permission.
Then, in order to assign the permission to view the device to some user, the admin should click on the view permission (link) just mentioned, create a User Policy (Create Policy... listbox) and select the users (assignees) in the Users field.
In order to assign the permission on multiple devices to the same group of people, use a Group or Role Policy instead (put the users in the same group before).
In order to assign the permission to groups of devices, use one Group/Role per group of device, then assign users to the Group/Role.
I have defined security properties of a login
I have 200 users .
How can I apply dynamically the same security properties of a login for all users login ?
Create a Role (through the GUI or T-SQL) with the required permissions, then add all 200 users as members of that role. Not sure if you can force the role to 'copy' permissions from a particular user, but from an auditing and maintenance perspective, it's far simpler to make required changes to a Role once and have them instantly inherited by all members.
Adding permissions to a role enables the given permission to all users in that role by default; this is something I want to avoid.
I want to be able to set permissions like "Booking: View own Bookings" at user level and not the role level.
Is there a module that already does this, or can someone give me some possible approaches or pseudo code of some kind?
Yes, there's the User Permissions module.
User Permissions provides an interface for giving additional permissions to individual users without the need to assign them to a special role. When this module is enabled, users with the 'administer permissions' permission can access the 'User Permissions' tab on each user's account.