Lesson 1: The big picture

There are three interconnecting concepts that provide flexibility to your release process. In this lesson, you will gain an understanding these concepts: permission, team, and role. This lesson is an introduction to how these building blocks interact to provide a flexible and secure environment.

Permissions, roles, and teams work together to allow a security approach that is both flexible and complex, according to the needs of your environment. Permissions are the cornerstone to implementing a security plan. A permission defines a single task within IBM® UrbanCode™ Release. One or more permissions are assigned to a role. Finally, roles are associated with a team. A team is made up of users or groups.

Let's use a restaurant as an example to help understand the relationship. In a restaurant, there are a number of tasks that keep a restaurant running smoothly. These tasks include:

Seat customers
Take orders
Cook the food
Give food to customers
Deposit money in bank

Think of each task as a permission to perform an activity.

There are different types of employees in restaurant, such as waiter, hostess, chef, busboy, and manager. Each type of employee fulfills a role needed to run a restaurant. Each role has responsibility for a set of tasks. For example,

The role of waitress has the permission to take orders and give customers their food, but not deposit money into the bank.
The role of chef has permission to cook the food.
The role of manager has permission to handle all tasks.

The following table show the roles and assigned tasks for a restaurant. Who has permission to collect payment from customers? Right, only the manager and cashier.

Table 1. Restaurant tasks and roles
	Seat customers	Take drink order	Take food order	Cook the food	Give food to customer	Clean tables	Sweep and mop floor	Collect payment from customer	Deposit money in bank
Manager	X	X	X	X	X			X	X
Chef				X
Host	X	X
Waiter One	X	X	X		X	X
Waiter Two			X		X
Cashier								X
Busboy						X	X

These same roles and tasks can be found in most restaurants. However, there could be more or fewer roles at different restaurants. For example, one restaurant is upscale and has two additional roles, Host and Cashier, that do not exist in a casual-type restaurant. There could be multiple types of the same role that have different levels of responsibility. For example, in the table above, there are two waiter roles: Waiter One and Waiter Two. Notice that the assigned tasks are different for the two roles. Waiter One has two additional tasks to perform than Waiter Two: take drink orders and clean tables.

Drafting a chart or table of the tasks and roles needed to complete the work provides the framework for creating the roles in the user interface. Getting to this point is the difficult part. It takes time to gain a complete understanding of your project to ensure that all the tasks and roles are identified. Once roles are defined and associated with one or more permissions, they can be reused to create different teams. Teams can consist of identical or completely different roles.

Graph showing roles in the two resturants.

Have you noticed that up to this point there has been no mention of users? It is important to understand that users are separate from the infrastructure of permissions and roles. Individual users or groups of users are assigned to a team and specific roles. Employees from each restaurant are assigned to a team for the restaurant where they work. For example, at Restaurant A, Dale is assigned to the Chef role and Jose to the Manager role. Employees can be given multiple roles: Allison is assigned to Cashier and Host roles. Graph showing roles and employess of two resturants.

Can Ted collect payments from customers?

Answer: No, he doesn't have that permission. Collect payment is a permission for the Cashier role.

What tasks are assigned to Lewis?

Answer: Seat customers, take drink and food orders, give food to customers, and clean tables.

Before you map users to teams and roles, planning what each user is required to do must be known. With a clear plan, the task of assigning teams and roles is simplified. Without a plan, it is possible for users to have more access than needed or not enough access to perform their work. In the following lessons, permissions and roles that are specific to IBM UrbanCode Release are covered.

Summary

The interlocking concept of teams, roles, and permissions can be used to ensure that users have the appropriate permissions to perform their work and not affect processes outside of their assigned scope. The interaction of the three approaches lets you create an infrastructure that is secure and flexible.

Checkpoint

What are the three concepts that provide user access to specific tasks?

Answer: Permission, roles, and teams.

Can a user or group be assigned multiple roles?

Answer: Yes. A user or group of users can be given several roles, which expand their scope of responsibility. How narrow or broad of scope given a role depends on the needs of your organization and how reusable the role permission relationship can be.