Understanding Identity and Access Management


ProKnow's Identity and Access Management (IAM) facilitates the management of user access to groups of resources. It comprises Workspaces, Roles, and Users. This article explains the purpose of these entities in ProKnow and offers a general method for setting up your organization.

Users, Resources, Groups, and Roles

A user is an entity (usually a person) who uses the system.

A resource is an entity in the system to which a user may be assigned a set of permissions. Resources include your Organization, Groups, Workspaces, Patients, and Collections. Resources are defined in a resource hierarchy.

A group is a collection of 0 or more users called members. Groups are organized into a group hierarchy. A user is an explicit member of a group if they belong to the group. A user is an implicit member of a group if they belong to a subgroup of the group.

A role is a set of permissions. Organizations may use built-in system roles or define their own custom roles.

Users, groups, and your organization may be assigned a role on a resource, giving that entity the permissions defined in the role on the given resource and all of its subresources.

Key Tenants

  1. Strive to keep the number of resource assignments to a minimum.
  2. Limit role assignments to only those which are necessary for each user to fulfill their duties.
  3. Favor using built-in roles over defining your own custom roles.

Setting Up Your Organization

Step 1: Define Groups and Add Members

A well-defined group hierarchy will allow you to keep the number of resource assignments to a minimum. Here are a few things to keep in mind as you set up your groups:

  1. A user is an explicit member of a group if they belong to the group.
  2. A user is an implicit member of a group if they belong to a subgroup of the group.
  3. At the top level of the group hierarchy is the organization. All users are explicit members of the organization.
  4. Groups have a maximum nesting depth of 5.

To illustrate these principals, consider the following example:

ABC Cancer Network
- Hospital A
  - Physicians
  - Physicists
  - Dosimetrists
  - Administrators
- Hospital B
  - Physicians
  - Physicists
  - Dosimetrists
  - Administrators
- Hospital C
  - Physicians
  - Physicists
  - Dosimetrists
  - Administrators
- Network Administrators

Some observations on this group setup are presented below:

  • We have defined a total of 16 groups under the Organization at a maximum depth of 3. Since all users belong to the ABC Cancer Network organization, we can use the organization to assign permissions that all users should have.
  • We have defined a Network Administrators group. We could add hospital network IT staff as members of this organization and limit their permissions to managing the directory of groups and users across the organization while preventing them from accessing any patients.
  • We have defined a group and several subgroups for each hospital within the network. We can add members to the subgroups Physicians, Physicists, Dosimetrists, and Administrators. These users will be explicit members of the parent Hospital group.
    • We can give the Administrators group permissions to manage access within their Hospital group and all its subgroups but restrict access to patient data. This might be an appropriate group for hospital IT staff.
    • We can assign physicians, physicists, and dosimetrists to their appropriate group.
    • The Administrators group can use the Hospital group to grant permissions for all members (explicit and implicit) of the hospital group.

Step 2: Add Resource Assignments

Remember that resources in the system include your Organization, Groups, Workspaces, Patients, and Collections. Note that some permissions only apply to certain resource types. For example, the Create API Keys permission must be applied on the Organization resource in order to have an effect. As another example, the Create Patients permission could be applied to the Organization resource (implying that the user(s) have access to create patients within all resources) or to a Workspace resource (implying that the user(s) as access to create patients within that workspace). Please note that when a resource is created, the user who created the resource will automatically be added as an Owner of the resource.

More information on managing resource assignments can be found in the Managing Access article.

Step 3: Define Custom Roles (Optional)

While its recommended that you use the built-in system roles, you can define your own custom roles for your organization if needed. For more information on defining custom roles, please see Managing Roles - Permission Sets.

Note that roles are designed to be composable. That is, more than one role may be assigned to a given user, organization, or group on a given resource. For example, if you want to grant a group the ability to manage structure set templates and scorecard templates at the organization level, you could simply assign the "Structure Set Template Manager" role and the "Scorecard Template Manager" role to the group.

Conclusion and Next Steps

Identity and Access Management is an important part of your ProKnow organization. Determining the needs of your organization is the first step toward ensuring that your account remains secure and your team stays efficient. Once you've thought about these needs, you're ready dive into these step-by-step guides:

Was this article helpful?
0 out of 0 found this helpful
Have more questions? Submit a request



Article is closed for comments.