TM1 Tutorials.com

The definitive guide to TM1 Security with examples

Security in TM1 is one of those things that can make a TM1 administrator go crazy over new requirements or over setting up a new user. Things do not get better with reading the documentation, which does not cover all aspects or the security inner workings. In the following post, the TM1 security is peeled layer-by-layer starting from the very basics of cube security and finished with multi-layer multi-group security setup. Let`s start our discussion on TM1 security with an excerpt from the documentation describing the different access privileges just to be sure that everyone is on the same page. The object-level security rights for TM1 groups are:

  • Admin – Group has complete access to a cube, element, dimension, or other object.
  • Lock – Group can view and edit a cube, element, dimension, or other object and can permanently lock objects to prevent other users from updating them.
  • Read – Group can view a cube, element, dimension, process, or chore, but cannot perform operations on the object.
  • Reserve – Group can view and edit a cube, element, dimension, or other object, and can temporarily reserve objects to prevent other users from updating them.
  • Write – Group can view and update a cube, element, dimension, process, or chore.
  • None – Group cannot see a cube, element, dimension, process, or chore, and cannot perform operations on the object.

Sample TM1 model used in this post

For the purpose of explanation the following TM1 model is used (as seen by ADMIN): sample_model_1 sample_model_2 Cubes A, B and C are the same and have two dimensions: Dimension A and Dimension B. Dimension A is comprised of two elements: Element A1 and Element A2; Dimension B is comprised of two elements: Element B1 and Element B2. The TM1 model is deliberately made as simple as possible so that it does not stand in the way of understanding the actual security model.

Single Group Setup of Security in TM1

Group-User relationships Security is applied on per-group basis, not on per-user basis. This does not mean that there cannot be user specific security setups as a group can have only one user assigned to it. One user assigned to a group: single_group_1 Multiple users assigned to a single group: single_group_2 In the two cases above, all users assigned to the Group A have identical privileges. Note: only for the example above it is assumed that there is no Group B, thus Client AB is assigned only to Group A.

Example 1: Simple case with no overlap

Adding the first layer of security – Cube security: Client A is assigned exclusively to Group A. example_1_1 The model as viewed by Client A: Cube A: Visible and has WRITE access; Cube B: Visible and has READ access; Cube C: Not visible. example_1_2example_1_3example_1_4

TM1 Security privileges relationships within one group

It is important to mention that security privileges within one group might be overlapping i.e. security for a data cell (an intersection of elements) can be defined by cube, dimension, element and cell security at the same time. If you apply different security rights to theobjects that identify a cell of data, TM1 applies the most restrictive security right to the cell. For example, a user has READ access to a cube and WRITE access to the elements in this cube. In this scenario, the READ access of the cube overrides the WRITE access of the elements, and the user can view cube data but cannot update the cube data. If the above scenario is reversed i.e. a user has WRITE access to a cube and READ 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. The key thing to note here is: Dimension security does not directly affect data security; NONE access does restrict a user from seeing a dimension hence the cube hence the data. From one side, there is no difference between READ and WRITE and ADMIN access privileges for data access; on the other side, it applies different rights for attributes and formatting. The only exception is cell security, which overrides everything else.

Example 2: Overlapping privileges within one group

In this example, all layers of security are in use with the exception of cell level security:

Cubes Dimensions Elements
Example_2_1 Example_2_2 Example_2_3Example_2_4

In the following example READ overrides WRITE for Elements/Cubes. Example_2_5 Cube B is still READ despite the fact that Element A2 / Element B2 is specified as WRITE. Example_2_6

To eliminate the variable of the dimension security, the next setup the element security is switched around:

Cubes Dimensions Elements
Example_2_7 Example_2_8 Example_2_9Example_2_10

Cube A is the same as in the previous iteration with the writeable cell shift that reflects the element security changes. Example_2_11 Cube B is still READ despite the fact that Element A1 / Element B1 is specified as WRITE. Making a change to dimension security makes users unable to see the cubes that use the dimension, it also changes all Cube security to NONE: Example_2_13 Example_2_12

 Multiple Groups Setup

A user who is a member of multiple groups receives the highest level of rights from all groups. For example, in the sample data, a user is a member of two groups.

  • Even Numbers, which has WRITE access to the CostCentre2 and CostCentre4 elements in the Cost Centre dimension, and READ access to the other elements in the Cost Centre dimension.
  • Odd Number, which has WRITE access to the CostCentre1 and CostCentre3 elements in the Cost Centre dimension, and READ access to the other elements in the Cost Centre dimension.

TM1 gives this user WRITE access to CostCentre1, CostCentre2, CostCentre3 and CostCentre4, and READ access to the other elements in the Cost Centre dimension. To resolve complex conflicting security setups, TM1 overlaps groups first, then applies the lowest combination within the combination of groups. Assuming the Blue Quadrant is what is object-by-object setup in TM1. The Yellow Quadrant is what happens in TM1 before on group-by-group basis (based on the Blue Quadrant privileges). The Green quadrants are derived the highest-then-lowest way:

  1. Combining group privileges first – applying the highest privileges.
  2. Combining the privileges within the combination of groups – applying the most restricted.

In other words, the correct order is 1-3-4. 1-2-4 would yield wildly different results and it is NOT used by TM1.

1. Objects Group A Group B 3. Objects Group A+B
Cube A WRITE NONE Cube A WRITE
Cube B READ NONE Cube B READ
Cube C NONE WRITE Cube C WRITE
Dimension A WRITE WRITE Dimension A WRITE
Dimension B WRITE WRITE Dimension B WRITE
Element A1 WRITE READ Element A1 WRITE
Element A2 WRITE READ Element A2 WRITE
Element B1 READ WRITE Element B1 WRITE
Element B2 READ WRITE Element B2 WRITE
2. Output Group A Group B 4. Output Group A+B
Cube A READ NONE Cube A WRITE
Cube B READ NONE Cube B READ
Cube C NONE READ Cube C WRITE
Dimension A READ READ Dimension A WRITE
Dimension B READ READ Dimension B WRITE
Element A1 READ READ Element A1 WRITE
Element A2 READ READ Element A2 WRITE
Element B1 READ READ Element B1 WRITE
Element B2 READ READ Element B2 WRITE

Example 3: Simple multi-group setup

In this example the groups are very similar in setup, the only difference is Dimension A elements setup. Group A has WRITE Access to A1,Group B has WRITE access to A2.

Cubes Dimensions Elements
example31 example32 example_3_4example_3_3

 

Client A / Cube A Client B / Cube A Client AB / Cube A
example_3_5 example_3_6 example_3_7

Client AB has access to both Elements A1 and A2 i.e. element by element the highest privilege was picked.

Example 4: Multilayer multi-group setup

In this example the groups are different in setup and neither of the groups has WRITE access to the Cube A or to the Cube C data. Once combined, it is applying highest privileges, making the result setup counterintuitive. Dimensions are kept as WRITE and; as we already know, the dimensions are out of this equation.

Cubes Dimensions Elements
example4 example_4_2 example_4_3example_4_4

Client A: As per the setup, Client A has access to both Dimensions A and B and cubes A and B. Server explorer view: example_4_5 Checking the Cubes A and Cube B setup further:example_4_6example_4_7 Conclusion: Client A does not have write access to any of the cubes.   Client B: As per the setup, Client A has access to both Dimensions A and B and cubes A and B. Server explorer view: example4_8 Checking further: example4_9 Conclusion: Client B has READ access to Cube C.   Client AB: As per the setup, Client A has access to both Dimensions A and B and cubes A and B. Server explorer view: example4_10 Checking further: example4_11 Conclusion: Neither Group A nor Group B have WRITE access to anywhere in the model, while the combination has WRITE access to any of the cubes, yet the combination of the two yields counterintuitive but valid result – Cubes A and C are writeable.


Categorised as: IBM Cognos TM1, TM1 10.2


6 Comments

  1. This is more helpful.
    🙂 you are the best Ivan. keep it up.

  2. Terry says:

    Great. This is realy an intuitive and clear explaination on the principle of TM1 security.

  3. sharad says:

    🙂 Really an useful guide for TM1 Security …Thank you !

  4. cognos tm1 is enteprises planning softwarefor the planning,analysis,budgeting,foecasting and reporting..

    now we are using the cognos tm1 10.2 version..

  5. Amardeep Bisla says:

    😀 Very well explained. Thanks

  6. Joseph Grandchamp says:

    Thanks for that article. Note that in 10.2 new feature change read order: “cell security (where it is specified – i.e. there is an entry in the cell security cube) overrides element security, the READ”
    http://www-01.ibm.com/support/docview.wss?uid=swg21651554

Leave a Reply

Your email address will not be published. Required fields are marked *