Lesson 3: Roles

If we think of permissions as the building blocks that define the various tasks to be performed, roles take those blocks and organize them into sets of tasks to be performed by a user or group of users. In this lesson, you will learn about predefined roles, modifying roles to fit your organization, and how permissions are assigned to roles.

After a user is defined, they have very limited access to the release. They can only view information on the dashboard. Depending on the tasks that a user has responsibility to perform and their "need to know," they are assigned to roles. Roles in IBM® UrbanCode™ Release are based on a set of defined permissions. It is the assigning of a role to a user that gives the user permission to complete their tasks related to the release lifecycle.

Roles are not directly assigned to users and groups of users. Users or groups are assigned to a team with a specific role. You will learn more about teams and the relationship to roles in the next lesson.

Graphic of person

Defined roles

There are several predefined roles that are included with the product. They cover the types of roles that are typically part of every release team. Graphic showing the predefined roles.

The predefined roles might not completely reflect your team, so you can add roles. Because a role is defined by the permissions assigned to it, you need to first understand permissions.

Exploring roles

  1. Start the IBM UrbanCode Release user interface.
  2. From the dashboard, click Manage Security, and then click Manage Roles.
    The list of defined roles are displayed. Any roles listed other than the ones described in the previous section have been added to your installation of the product.
  3. Let's begin by looking at the Administrator role. Click the edit icon () to the right of the Administer role. A list of all permissions is displayed.
    The permissions with a check mark are assigned to the role that you are viewing. As you can see, all permissions are checked for the Administrator role. The default Administrator role has all permissions.
  4. Permissions can be removed and added to a role, including the predefined roles. Keep in mind that all users assigned to the role are affected by the modifications. Caution should be taken in modifying roles that are used across teams.

    To remove a permission from a role, remove the check mark for the permission. For example, removing the Manage System Settings permission removes the ability of users given this role to access the System Settings user interface. The screen capture below shows the Settings page before the change.

    Screen capture of Settings page.

    After removing the Manage System Settings permission, the Settings page is shown in the screen capture below. Notice that System Setting is not available when a user that is given the administrator role logs in. Screen capture of Setting pages after permission change.

  5. A role cannot be defined with two different sets of permission to accommodate two users. However, you can define another role with the same or similar permissions. For example, you can define another administrator role for a user that only have authority to manage security.
    1. On the Manage Roles page, click Add New.
    2. Type a name for the new role, such as Security Administrator. Type a description for the new role, such as Administrator for security features.
    3. By default, newly created roles have no permissions. In the System section, select the following permissions:
      • Manage Security Realms
      • Manage Users & Groups
      • Manages Roles & Permissions
      • Manage Teams & Membership
    4. Save your changes.
      You now have an additional role that users and groups can be assigned. The new role is displayed in the list of roles.Screen capture of Manage Roles page.

Administrator role versus the admin user

The Administrator role can be assigned to any user. The permissions for the administrator role can also be modified. As seen in the previous activity, it is possible to have two types of administrators, each with a set of different permissions. For example, one administrator has responsibility for tasks related to security and another to tasks related to release process. You can control the scope of the administrator by defining multiple administrator roles and assigning users accordingly.

The admin user is a predefined user . This is superuser with all permissions. The admin user can perform all product tasks. This user cannot be deleted. Also, permissions cannot be removed from this user. It is important that this user ID be protected. When the product is installed the password for this user ID is admin. It should be changed and maintained by the user responsible for securing this user ID.

Summary

Roles define jobs to be performed by a user or group of users. Roles are a collection of permissions that add another layer to an organization's security model. Grouping permissions into roles that match how work is performed in the organization provides a method to ensure users have access only to what they need to accomplish their responsibilities in the release process.

Roles are not directly assigned to users and groups of users. Roles are assigned to a team, and they can be used by multiple teams. Users or groups are assigned to a team with a specific role.

Graphic of checkmark.Checkpoint

Can the permissions associated with a role be changed?
Answer: Yes, changes made to a role affects all users assigned to the role.
What permissions does the predefined Release Manager role have?
Answer: The Release Manager role has all permissions associated with applications, releases, deployments, initiatives and changes,and statuses. In addition, the Release Manager can edit environment activities which is a system level permission.