Roles and permissions

10Duke Enterprise provides a role-based access control (RBAC) capability that allows fine-grained control over users’ access in the system.

10Duke Enterprise uses built-in roles, internal roles, and organization roles for controlling user access to protected resources in 10Duke Enterprise. Each role is granted permissions, which allow access to data and features. In addition, client roles and client permissions can be used to control access to resources in your client applications.

10Duke Enterprise provides a set of predefined roles with permissions that cover some common access control needs in 10Duke Enterprise, and you can create additional roles to match your requirements. You can also set up organization role templates to ease the onboarding of your B2B customers.

You can manage roles, grant permissions, and create organization role templates using the 10Duke SysAdmin tool. You can also manage all roles except for built-in roles and grant and manage permissions through the 10Duke Identity Management REST API.

Permissions

A permission allows access to a protected resource. You grant permissions to users by adding the permissions to roles and then assigning the roles to users. You can also grant permissions directly to your client applications when needed.

Each permission specifies a protected resource and the actions that define the access rights to that resource. For example, the permission Organization.update can be used to grant access to editing (the action) organization data (the resource) in 10Duke Enterprise.

10Duke Enterprise supports two types of permissions: internal permissions and client permissions.

Internal permissions

10Duke Enterprise provides a large set of default internal permissions for controlling access to protected resources in 10Duke Enterprise, such as Organization in the example above.

You can grant the same permission to different types of roles, and the type of the role determines the actual scope of access allowed.

For example, if you grant the permission Organization.update to an organization role of some organization, users with that role get access to editing that organization’s data. If you grant it to an internal role, users with that role get access to editing the data of all organizations.

10Duke Enterprise also supports the use of custom permissions, with custom resources and actions, to match any custom extensions in your deployment.

For security reasons, 10Duke doesn’t provide exhaustive documentation on the possible permissions. Contact the 10Duke Integration Support team for further help and information on configuring access to 10Duke-protected resources.

Client permissions

You can create client permissions to control access to resources in your client applications, and grant these permissions to client roles.

From the 10Duke Enterprise point of view, client permissions are just metadata stored in the system, and it’s the client’s responsibility to enforce them to control access.

A client application connected using OIDC/OAuth can request for the client permissions granted to the user. See information on the custom scope to use to receive the client permissions in the ID token or OIDC UserInfo.

Permissions vs. granted permissions

At a technical level, a permission more specifically specifies only the resource it protects, and a granted permission specifies both the resource and the actions granted to that resource.

You can manage granted permissions using both SysAdmin and the Identity Management REST API.

The Identity Management REST API allows more visibility specifically to the permissions that specify a protected resource. For example, you can retrieve information on all the permissions available, or even delete a permission from the system.

Types of roles

10Duke Enterprise uses four types of roles: built-in roles, internal roles, organization roles, and client roles.

A role is just a “container” for permissions: the role itself doesn’t grant access to anything. When you assign a role to a user, the user gets the permissions that the role has been granted.

Built-in roles

Built-in roles are predefined system roles that are associated with built-in logic in 10Duke Enterprise.

You cannot assign built-in roles to users: 10Duke Enterprise dynamically applies these roles to a user based on the user’s context. For example, every authenticated user has some basic access rights in the system, such as the ability to accept invitations and edit their own profile, and a user who belongs to an organization’s “employees” user group has wide view access to the organization’s data in API interactions.

Internal roles

Internal roles are global roles used to grant permissions in the scope of the whole system. In addition to being used to control user access to SysAdmin, internal roles are used when controlling access for integrations to third-party systems, such as your CRM or e-commerce system, which need wide access to operating on 10Duke Enterprise data.

As an example use case, you might need different levels of access to SysAdmin for your own system administrators. 10Duke Enterprise provides a default “SuperAdmin” role that allows full access to SysAdmin, but you may want some administrators to have limited access to features, or even just read-only access.

Organization roles

An organization role is always specific to a certain organization, and it controls access to that organization’s data. Organization roles are used, for example, to control user access to 10Duke OrgAdmin or any custom tool you might be providing to your B2B customers.

For each new organization, 10Duke Enterprise creates a default “OrgAdmin” organization role that provides access rights to OrgAdmin. You can create additional organization roles as needed to support your customers’ requirements for their administrator access.

To speed up the onboarding of B2B customers, you can create templates that allow you to quickly set up suitable organization roles for a new customer’s administrators. 10Duke Enterprise provides a default template that is used for the default “OrgAdmin” roles.

An organization role can also inherit permissions from other organization roles of the same organization, and from client roles.

And the B2B customer’s users who only need to consume the organization’s licenses? They don’t need any organization roles—they just need access to the licenses through a user group.

Client roles

In many cases, the license controls what the end user can and cannot do in the client application. However, there may be cases where role-based access control for client applications is needed.

With client roles, your client applications are able to externalize their roles and permissions to 10Duke Enterprise. This allows centralized access management so that your system administrators can manage everything in one place. You can use client roles for client applications that are connected using OAuth.

Through client roles consisting of client permissions, you can control who has access to what content and functionality in your application. The client application is responsible for enforcing the client permissions to control end user access in the application.

For example, let’s say you have a client application for managing documents. You allow all users to view documents but only some users to edit them. With Document as the protected resource in your client application, you could create a client role “Editor” and grant the client permission Document.edit to it, and then assign the client role to the applicable users.

You can use client roles that apply to all of your client applications as well as client roles that are specific to a certain client application.

In addition to assigning client roles to users, you can set organization roles to inherit client permissions from client roles.

Client-elevated privileges

In addition to granting permissions to users through roles, you can also grant internal permissions, or “elevated privileges”, directly to trusted client applications so that they can access protected resources in 10Duke Enterprise.

You can grant elevated privileges to client applications that are connected using OAuth 2.0. With most of the OAuth authentication flows, the client application gets authorization to access the 10Duke APIs based on the authenticated user’s roles and permissions. However, the client credentials grant flow doesn’t involve any user, so you may need to grant permissions directly to the application.

See instructions on how to grant permissions to an OAuth client application in SysAdmin.