NextGen Consulting

Implementing Role Based Authorization

Implementing Role Based Authorization

The three ingredients required to compose an RBA security mechanism are:

• Controlled operations (functionality)
• Controlled data
• User roles (Global, Team, User)

 
A matrix match of all tree components will allow controlling functionality and or controlled data. Both depend on specific data instance (object) and the user role that are evaluated at run-time.

In order to implement RBA one has to identify the functions and data to be controlled, the roles that should be granted access to those functions and data, and the rules that determine when access is granted.

A.   Identifying controlled functionality

For example, let’s assume the following functionality needs to be restricted:

• View accounts
• Create opportunities
• View opportunities
• View selected tabs in the Opportunity window
• Change Case status

 

Business functions can be defined in terms of basic operations or UI elements in the CRM application modules. These business functions are defined as Controlled Business Objects.

Restricted Data

Restricting data visibility (for a specific database object), requires identifying that the database table related with that object. The CBO Data Service (JPOMS) controls access when retrieving the data from the CRM database. You do not need to identify application components for the view function.

Restricted Operations

In order to restrict functions (application components) that performs the business operations, certain application elements need to be identified:

• The UI component and server side code (worker bean, XBean) handle requests to perform the business function
• The services or processes which performs the business function
• The status transitions associated with the business function

 

To control the operation of adding team members on the Account Overview page the following application components are identified:

• The UI component to be controlled for this function is the Team Members tab on the Account Overview page
• The server side code (worker bean) that handles the operation is com.clarify.isales.team.workerbean.TeamRoleAddWB.

 

Smart Client administrator UI screens allow identifying the application components which perform specific functions related with specific data object.

B.   Identifying the affected data – Controlled Objects

This is the data affected by the controlled operation. For example, filtering accounts data (restricting access to viewing account records), affect the database table bus_org.

The table containing this data represents the controlled object.

When setting up RBA, the controlled objects define the previously defined controlled business operations.

Instance-specific operations

Functionality related with existing data in the database, and which are authorized for some objects and not authorized for other objects, are called instance-specific functions.

• For the “view opportunity” business function, the opportunity table represents the controlled object.
• For a “modify forecast item” business function, the frcst_itm table represents the controlled object.

 

Global functions

Certain business functions that do not operate on existing data in the database are called global functions, such as:

• Create operations, since there is no object instance yet present in the database (I.e create territories or accounts).
• External call functions that call external systems (such as services and processes that launch third-party software).

 

Global Control Object

Since global functions do not affect existing database data, their related controlled objects are a special object called global. When setting up RBA, these business functions are defined under the default global controlled object.

C.   Grant Access to Controlled Objects – Define Roles

Who should have access to this functionality and what is the context in which authorization is to be applied to the controlled functionality?

RBA use roles to identify who has access to controlled functionality and data.

For example, allowing the members of an account team to view the opportunities under their respective accounts. An account team member has a role and opportunities related with accounts represent the context in which authorization is applied.

Additional conditions that should be used to restrict access

In order to further restrict access to functionality and or data, an expressions or combination of roles are used.

Setting Permissions 

After determining the data to control and the roles, we should set the kind of permission granted to allow roles to access controlled business functions.

For a given role, any one of the following permissions can be assigned to a controlled business function:

• Grant permission with no condition
• Do not grant permission at all
• Grant permission with a condition.

 

Authorization Matrix

Authorization Matrices are the place where you will map controlled business functions to the roles.

It is possible to grant access to roles associated with authorization matrices by assigning permissions to different roles in different authorization matrices. Thus, a sales administrator global role in the Global Roll Matrix (GRM) can have a single permission and a sales manager in an account Team Role Matrix (TRM) may have a different permission for the same business function.

Granting an unconditional permission 

When assigning the ‘Grant’ permission to a role, that role is given a permission to perform the controlled business function. ‘Grant’ permission overrides all other permissions.

Once a user has a Grant permission for a function, that user is permitted to perform that function even if he is not granted permission in any other authorization matrix for that controlled function.

Denying permissions 

 ‘Not Granted Here’ permission

When the ‘Not Granted Here’ permission is assigned to a role, it means that permission is denied for that role with regard to the controlled business function using that authorization matrix.

Not Granted Here means that the function is not given permission by this role here. However it does not mean that users with that role cannot perform the function.

‘Not Granted Here’ is a non-restrictive permission. If the users have permission for this controlled business function under a different role, that Grant permission overrides the ‘Not Granted Here’ permission.

Not granting permission is not the same as denying permission. RBA uses the combination of all matrices to determine the permission for a business function. If any matrix grants permission to a role, that role is allowed to perform that controlled business function even if user also has another role that does not have permission.

Granting a Conditional Permission Using an Expression 

When a role is assigned with ‘Expression’ permission, it grants or withholds permission to the controlled function depending on the result of an evaluated expression.

If the expression evaluates to true, the role is assumed to have ‘Grant’ permission and if the expression evaluates to false, the role is assumed to have ‘Not Granted Here’ permission.

The Smart Client administrator UI provides special UI which allows using a ‘path builder’ to compose the expression.

Example:

Use the expression: 

• $focus:name=‘Account1’   –  to allow accounts with name ‘Account1’
• $User:login_name=‘sa’      –  to allow only user ‘sa’

 

                                                                  Path builder to help writing the expression

How Permissions Are Evaluated 

Permissions are evaluated using the user roles, the business function, and the object instance.

Global roles are checked first to see whether the user is assigned any of the global roles that are permitted to perform the function (Global Roles for a user are known by the CRM application when the user logs in). If a user is not assigned any global roles that are permitted for the business function, every TRM and URM are checked for the business function to see if the user is assigned a role with permission for that function.

 Identifying Authorization Matrices

Which authorization matrices should be used to assign permissions to different roles for the controlled functionality?

Assuming we would like allow an opportunity team member (team role) to view accounts associated with opportunities. The authorization matrix used for the opportunity team will be the Opportunity Team Role Matrix. The authorization matrices for different roles must be identified.

An authorization matrix determines which roles have permissions to which business functions. As an example, an authorization matrix for an “Opportunity Owner” authorization domain may specify that the opportunity owner has access to the “view opportunity” business function for that opportunity.

Based on the types of roles used, RBA can use three types of Authorization Matrices:

• Global Roles Matrix (GRM) for global Roles
• Team Role Matrix (TRM) for Team Roles
• User Role Matrix (URM) for User Roles

 

When setting up RBA, a grid-like UI is used to implement the authorization matrices.

When all  RBA settings are ready, they should contain at least one GRM and one or more TRMs and URMs.

When users try to use a controlled business function, RBA uses the combination of all matrices to evaluate if they are permitted to access the controlled functionality.
A user who is granted permission in any one of the matrices has access to that controlled function.

Users not granted permission in any of the matrices are denied access to that controlled function.

Using the Global Role Matrix (GRM) 

The Global Role Matrix (GRM) relates the controlled business functions with the Global Roles.

The GRM is checked first for evaluating permissions when the user logs into the CRM application.

 The GRM is accessed through the following CRM Administrator UI screen:

 

                                                                               Global role Matrix window

Controlled Objects and business functions are added into the matrix using the ‘Controlled Objects’ UI tab. They are added from the global pool of controlled objects defined in the application.

Using the Team Role Matrix (TRM) 

The Team Role Matrix relates controlled objects and functions with Team roles; enabling the function for users in the team with the role specified.

The CRM application already provides several pre-defined TRMs for Account, Opportunity, and Territory objects.

If a user has multiple roles within the same team, the effective permission is the sum of all the permissions granted for that user in that team.

Using the User Role Matrix (URM) 

The User Role Matrix relates controlled objects and functions to user roles; enabling the function for users with the particular role (ex: case owner)

The URM is a special kind of TRM. The only difference between them is that a TRM uses team roles previously defined, while the URM uses roles assigned by the application logic.

The URM is accessed through the following CRM Administrator UI screen:

 

                                                                            User Role Matrix window

Performance Considerations

Enabling Authorization affects the performance of the CRM applications (due to multiple checks for evaluating permissions).

Here are some guidelines for minimizing performance penalty when implementing RBA:

• Use global roles if possible. Checking permissions for global roles is faster than checking them for team and user roles.
• Define as few controlled business functions as possible (use combination of functions…).
• Define as few team roles as needed. If two team roles have exactly the same authorization policy, combine the two roles.
• Do not duplicate permissions when one role is a superset of another role. Instead, assign user to both roles.

 

Disabling Authorization 

RBA is enabled by default for Amdocs CRM applications. However, you can disable authorization checking using RBA at the following levels:

• To disable RBA for at the applications level, use the DisableAuthorization configuration item, and set it the ‘1’.
  As a result, RBA will not be active at all for all roles and all functions.
• To disable RBA for a global role, use the Disable Authorization for this Global Role check box on the Role tab of the Global Role Matrix window in the Administrator UI.

06/05/2010 - Posted by Yuval R. | Amdocs, CRM, CRM, General, Uncategorized