NextGen Consulting

Role Base Authorization

Role Base Authorization (RBA) is a security feature for AmdocsCRM smart (and thin) client applications.
It facilitates the setup and administration of an organization’s authorization scheme, without requiring customizing the CRM applications.  With RBA, it is possible to create a security model based on the organization’s structure so that the application can precisely apply security that reflects that model.      

 To implement security using RBA, certain areas of the Amdocs CRM applications functionality that require authorization need to be defined. Additionally, the organization model needs to be mapped to the AmdocsCRM applications.    The organization model is built around what people do, their level of responsibility, the people they work with, the teams they belong to, and the business entities (accounts or cases for example) they work on. RBA collectively refers to these factors are as roles.    A CRM application can be regarded as a combination of data and application functionally that enable accessing that data.
RBA allows managing the intersection between the roles that model the organization and the controlled data.    

A simple RBA scenario defines roles which may roughly correspond to job descriptions, and each role is authorized to work with
different parts of an application.    

        

The figure shows four employees organized into two roles – Account Administrator and Support Administrator.
The Account Administrator role is authorized to work on everything related to Accounts, while the Support Administrator role is authorized to work only on Account Overviews.    

 The advantage of using such Roles to define authorizations is when the organization policy changes, only the authorizations associated with the roles will be changed, and no change at every user level will be necessary.    

Roles are organized into 3 categories:    

• Global roles provide authorization that spans an entire organization.
  They are equivalent to Privilege Classes used in Classic Client, but a same user may have several global roles and only one Privilege Class
  Global roles are used to authorize access to similar instances of work. You can for example authorize or disable access to all accounts, without specifying which account.
  Global roles are mostly recommended to use. Using Global roles creates the most efficient database queries, hence result with best performance.
   
• Team roles associate a group of individuals to a business entity, such as an account or an opportunity.
  Team roles can be used to authorize access to a specific instance of work that a selected group of people can work on.
  For example, for sales operations it is common to form teams of people and assign them to work with particular accounts, or within particular territories, or on specific opportunities.
  Using Team Roles, it is then possible to authorize access to those specifics accounts, territories, and opportunities only to the team members of those entities.
  Team Roles are always defined against a domain object, which is the CRM database object representing the data to control, such as account (bus_org), opportunity or territory.

• User roles refer to special relationships between a user and an object of the application. For example, the Case Owner.
  User roles can be used very much like team roles, to authorize specific instances of work for selected users. With user roles the implementor needs to identify existing relation between a user and an object instance (established by the application logic) and give it a name. When RBA is used to identify a relation, authorization can be applied to it as well as to any other related objects

When RBA checks to see if a logged-on user is authorized to perform a particular task or to access some data, it checks if the user has a global role, team role, or user role that grants permission to perform the task.      

Multiple roles usage
The following figure shows a global role and an example of teams that are authorized to work on the same types of data, but only on the specific instances of that data for which their team is responsible for.  

                   Global and Team Roles Authorization in RBA        

      

      

      

      

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

The diagram above show two account teams: East Region Account Team and West Region Account Team.
Account Administrator role held by John Stevens is authorized to see all accounts.Each team has assigned employees and two associated roles (Account Manager role and Sales Representative role).  

East Region Account team is authorized to work only on the East Region Accounts, while the West Region Account Team is authorized to work only on the West Region Accounts.   

 The boundaries indicate scope of authorization for each role within the team (depends on team role)    

Using RBA in the API (Application Programming Interface)
RBA can be used to control user interface (UI) elements for Thin client or Smart Client applications.
Using RBA, various types of UI controls such as buttons, menu items, text boxes, tabs, etc can be selectively enabled or disabled, made visible or invisible,  based on the user roles.    dditionally, the data shown as a search result can be filtered. Because RBA can be set up to give different permissions to different instances of data, certain user might sometimes see different UI controls on the same page, as different data are being worked on. For example, a user with permission to work on Corporate Accounts might see buttons enabled on Account Overview pages for Corporate Accounts and not on others, based on his roles and permissions.      

 

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