How to assign security rights to users and features to work on IBM planning analytics?

How to assign security rights to users and features to work on IBM planning analytics?

Securing software models, applications, and data is a top concern for all IT and business leaders. IBM Cognos TM1 supports robust security features to cater various levels of business users with variety of security options.

Security features in TM1 gives a wide range of opportunities for the administrator to control over users who access TM1 server with multiple authentication modes, Cube based, Dimension based, cell-level security, Element level security.

TM1 manages security by organizing TM1 users into groups.

  •   Admin
  • DataAdmin
  •  Security Admin

The above three are predefine administrative groups, other than these TM1 allows you to create your own custom groups. We will have simple dig on what these administrative groups are allowed.

Users that belong to the ADMIN group have full Administrator rights on the IBM Cognos TM1 instance. Users that belong to the Data Admin group have full data-related administrative rights on the IBM Cognos TM1 instance but cannot make security related changes.

Users that belong to the Security Admin group have Security Admin rights on the IBM Cognos TM1 Instance but cannot view any non-security related data in the instance. Security Admins also cannot change their own security credentials to include non-Security data.

When a user is assigned Admin rights, the following applies:

  • Cube: Members of the group can read, write, reserve, lock, and delete the cube. They can save public cube views. They can also grant security rights to other users for this object.
  • Element: Members of the group can access, update, reserve, lock, and delete the element. They can also grant security rights to other users for this object.
  • Dimension: Members of the group can add, remove, and re-order elements in the dimension, and can reserve or lock the dimension. They can save public dimension subsets. They can also grant security rights to other users for this object.
  • Application: Members of the group can see the application, use references within the application, and create both public and private references in the application. When a group has Admin privilege to an application, members of the group can set security privileges for all references and sub-applications within the application for other groups but not their own group.
  • Reference: Members of the group can use the reference, as well as update or delete the reference. They can publish private references, and privatize public references.

 Object-level Security with TM1:

The Object-level security within TM1 will improve the accuracy of your data by ensuring that only the users entitled to change data at a given intersection point will be doing so, and allows for unique configurations by personalizing the security rights of each individual group. It is very much important to know how exactly it works.

The object security can be implemented at 4 different security levels.

  •  Cube-level security
  •   Dimension-level security
  •   Element-level security
  •  Cell-level security

Example: Simple Cube Security Implementation

We will start with Adding Users/Groups to TM1.

  • In TM1 Architect: Server Explorer, right click PData, select “Security”, and click on “Clients/Groups…

  • As we discussed earlier by default TM1 creates the Admin user that is a member of the Admin group

  • We will add users and groups.
  • From the “Clients” menu, click “Add New Client”


In the “ Enter New Client Name” box type “Mohan”

  • Click OK
  • Repeat this step for Nasser, Anusha, Rea

From the Groups menu, click “Add New Group”

  • Add the following groups:
  1.    Sales Manger
  2.    Performers

Newly added groups

 

  • Assign Groups to the Client
  • In TM1 Architect: Server Explorer, right click Cubes, select “Security Assignment”

Highlight each call under “User Groups” to assign rights to the Cubes using the radio buttons at the bottom of the screen

  • Anusha is assigned exclusively to Performers
  • The Model as viewed by Anusha: visible PNLCube is assigned with Read access, PriceCube is assigned with None access, SalesByQuarterCube is assigned with Write access.

When you want to identify the cell of data, then you can apply different security rights to the objects so that we can identify the cell of data. IBM Planning Analytics applies the most restrictive security right to the cell. For example, a user has WRITE access to a cube and READ access to the elements in this cube. In this scenario, the READ access of the cube overrides the WRITE access of the cube, and the user can view cube data but cannot update the cube data. If the above scenario is reversed i.e. a user has READ access to a cube and WRITE access to the elements of this cube, then READ access still applies, and the user can view cube data but cannot update the cube data.

 

Conclusion:

The Most important concept here is, Data security is not directly affected by the dimensional security; NONE access does restrict a user from seeing a dimension hence the cube data. In one corner, there will be no difference between READ and WRITE and ADMIN access privileges for data access; on the other side, Attributes and formatting will be accessed with different rights. Cell security is only exceptional criteria, which overrides everything else

Categories: TM1
Comments are closed.