Image source: https://docs.confluent.io/current/security/rbac/index.html

Permissions with WSO2 Identity Server

Typed-Resource Permissions for your Applications and Business Data

Introduction

A permission in IAM is defined as, a combination of a resource and one of its corresponding actions. Permissions are a fundamental element of any authorization decision.

Following are the typical permission levels in increasing order of granularity:

1. Typed-resource level— The permission specifies the type of the resource, rather than the exact instance of the resource.
2. Instance-level — The permission specifies the exact instances of a resource type.
3. Attribute-level — The permission specifies an attribute of a resource type.

A group in IAM is defined as, a named collection of users. In practice, you most often don’t manage access rights at an individual user level. Rather you create groups of users, and manage access rights for the groups. This means that you have fewer number of entities to manage access rights for. Groups are generally managed in the userstore and typically express the organization structure.

Typed-Resource Permissions

Typed-Resource permissions are used to define access rights that are to be applied to all resources that are of a particular type. This type of permissions are useful if your authorization requirements and constraints are based on the resource type rather than the resource instance itself. Resources within an application can be typed based on the data they encapsulate or the functionality they provide.

For example, in a customer care application where the help desk user can operate on specific customer accounts, it may not be required to define a permission per customer account to read customer data. Rather, it could be effective and sufficient, to define a single permission to read customer account data for all customer accounts.

A role (my discussion here is limited to static roles; for a discussion on dynamic roles see [1]) in IAM is defined as, a named collection of permissions. In practice you most often don’t manage access rights at an individual permission level. Rather you create roles, and manage the assignment of users to those roles. Roles are created by identifying the common sets of permissions that are needed by all the actors of the system when performing their corresponding functions.

Use Cases

Now we will take a closer look at different use cases related to permissions, that can be supported by WSO2 Identity Server, as of its latest release at the time of this writing.

In IAM permissions can be used in two types of scenarios:

1. Authorizing users to application level resources (application bound permissions)
2. Authorizing users to API resources (API bound permissions)

Use cases 1–4 below are on application bound permissions, while use case 5 is on API bound permissions.

Use Case 1: Managing User Entitlements via Typed-Resource Permissions for Custom Web Applications

Consider a scenario where there are multiple custom web applications or SAML2 compliant web applications, that are implemented using fine-grained entitlements using typed-resource permissions. The applications don’t have sophisticated permission management capabilities. Managing user entitlements in each and every application could turn out to be a nightmare.

The requirement is to avoid building a sophisticated entitlements management capability in each application, instead, allow user entitlements for the application to be managed centrally and dynamically.

This is the most traditional form of managing user entitlements. That is, users are allowed or denied to access certain parts of the application, based on the permissions they’ve been assigned.

WSO2 Identity Server, until its latest version, only supports managing typed-resource permissions out-of-the-box.

Capabilities

• Ability to express permissions as typed resource + action.
• Ability to support hierarchical permissions to represent hierarchical resources.
• Ability to return user entitlements in the authentication response for application side authorization.
• Ability to limit the user entitlements in the authentication response to the respective application. If not, in case of external applications, this can be considered unnecessary information leakage.
• Ability to support roles.
• Ability to return user roles in the authentication response.
• Ability to optionally send user entitlements related to administrative permissions in WSO2 Identity Server, if the application consuming the authentication response is an administrative portal that is consuming admin services of WSO2 Identity Server.

Use Case 2: Avoid management overhead with Internal Roles

There are two options we can choose from, to assign application permissions to users in WSO2 Identity Server: Internal roles and custom permissions.

If we represent permissions as Internal roles,

1. Since WSO2 Identity Server doesn’t support assigning groups to roles, each individual user needs to be assigned to all his/her corresponding Internal roles.
2. Managing roles by individual users becomes very difficult, when there are a large number of users.

Due to the above reasons, representing application permissions as custom permission is the most optimum way.

Capabilities

1. Ability to assign custom permissions to user groups
2. Ability to map user groups to application roles (service provider role mapping).

Use Case 3: Workaround to manage Groups and Roles in the same deployment

Currently WSO2 Identity Server doesn’t support two separate representations of groups and roles, in their most widely accepted definitions of the words. WSO2 Identity Server doesn’t allow you to assign groups to roles. As a workaround however, permissions can be used to represent roles, and thereby you can assign groups.

Use Case 4: Workaround for Hierarchical Roles

Consider a scenario where an organization needs to manage access to multiple applications for their employees. Each application could potentially have multiple modules. Each module has its own permission that controls access of a user. For the ease of administering these permissions, modules are grouped into a set of capabilities/business roles (static roles). An employee is assigned a role instead of a set of individual permissions.

Roles may have a hierarchical relationship between them. For example, in a banking scenario, a role like ‘employee’ and ‘branch manager’, could have a parent-child relationship. In other words, all permissions given to a bank employee, are inherited by branch managers.

Post log-in, when returning the authenticated assertion to the application, only the roles that are relevant to the application has be returned, in order to avoid unnecessary information leakage.

Provisioning roles to an employee requires approval. When displaying the applicable business roles for the employee, based on his/her designation, to the approver to approve the business role provisioning process, the business roles have to be categorized by applications and shown in a hierarchy for the approver to easily understand and review the list of business roles.

Given these requirements, since WSO2 Identity Server doesn’t support hierarchical roles as of the latest release of this writing, permissions can be used as a workaround to express hierarchical roles.

As with most IAM solutions, in WSO2 Identity Server we can’t directly assign a permission to a user. Therefore we have to create an exclusive role per user, and assign all the capabilities applicable to that user that (s)he is not inheriting via his/her group memberships, to that role.

Capabilities

1. Ability to define roles by application.
2. Ability to define hierarchical roles.
3. Ability to limit the roles returned in the authentication response to the respective application. If not, in case of external applications, this can be considered unnecessary information leakage.
4. Ability to query roles specific to an application for ease of administration tasks such as approvals.

Use Case 5: API-bound Permissions

In a service-oriented architecture, applications need to consume APIs to retrieve business data. Users are allowed or denied access to certain parts of the business data, based on the permissions they’ve been assigned.

Traditionally in web applications these two types were clearly distinct. However, with modern applications such as single page applications (SPA), this distinction is blurring. Today the best practices for authorization in SPAs, promote the use of JSON Web Tokens (JWTs) which can contain authorization information of a user, which can be consistently used to authorize a user at the frontend as well as the backend. This makes application development way more standardized and easier.

More specifically OAuth2 protocol defines “scopes” as a way of clients requesting for authorization levels and the OAuth2 authorization server responding with the granted authorization levels. The assignment of permissions to scopes are implementation dependent. For example, the scopes themselves can be considered as permissions. A more scalable way of doing this would be to assign a collection of permissions to a scope. Therefore mapping assigning user roles to scopes would also be a good option.

Capabilities

1. Ability to express API resources and actions as permissions.
2. Ability to group these permissions under a designated node, under “/permission/admin/applications/”. E.g. “/permission/admin/applications/resources/accounts” and “/permission/admin/applications/resources/customers”.
3. Ability to assign a set of those permissions to OAuth2 scopes.
4. Ability to assign roles to scopes for easier management of scopes.
5. Ability to define a XACML 3.0 policy that can authorize the requested scopes in an authorization grant request.

Summary

In this article I have explained what are permissions, what are the different types of permissions, and what are the current use cases surrounding permissions that are supported by WSO2 Identity Server, as of its latest release at the time of this writing.

References

[1] https://medium.com/@johann_nallathamby/how-to-dynamic-roles-in-wso2-identity-server-978d4c7aaae4