the definitive guide to tm1 security with examples · pdf file ·...
TRANSCRIPT
<title>The definitive guide to TM1 Security with examples</title> The security in TM1 is one of those things that can make a TM1 administrator go crazy over new requirements or over new user setup. Things do not get better with reading the documentation, which does not cover all aspects or it. This situation leads to some common misconceptions that are uncovered too. 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 with an excerpt from the documentation describing the different access privileges just to be sure that everyone is one 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 will be used (as seen by ADMIN):
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 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:
Multiple users assigned to a single group:
In the two cases above, all users assigned to the Group A would have identical privileges. Note: for the example above assume that there is no Group B, thus Client AB is assigned only to Group A.
Security Privileges Group A Client A
Security Privileges Group A Client A
Client AB
Example 1: Simple case with no overlap Adding the first layer of security -‐ Cubes: Client A is assigned exclusively to Group A.
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.
Security privileges relationships within one group It is important to mention that security privileges within one group might be overlapping i.e. a cell can be defined by cube, dimension and elements security at the same time. If you apply different security rights to the objects 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 would still apply, 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 cube hence 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 in terms of attributes and formatting. The only exception is cell security, which overrides everything else.
Combined lowest privelege
Cubes security
Dimensions (NONE or ELSE) security
Element security
Example 2: Overlapping privileges within one group In this example, we have all layers of security except cell level security: Cubes Dimensions Elements
In the following example READ overrides WRITE for Elements/Cubes.
Cube B is still READ despite the fact that Element A2 / Element B2 is specified as WRITE.
To eliminate the variable of dimension security, the next setup will switch elements around: Cubes Dimensions Elements
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:
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.
TM1 approach to security privileges overlap within one group and then nested onto multiple groups as follows:
Assuming Blue quadrant is what is setup in TM1 object per object.
Yellow quadrant is what we actually have in TM1 before combining groups: i.e. applying the lowest privileges first.
Green quadrants are derived the highest-‐then-‐lowest way i.e. combining group privileges first i.e. applying the highest privileges first, and only then 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 READ 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 4: Simple multi-‐group setup In this example the groups are very similar in setup, the only difference is Dimension A. Group A has WRITE Access to A1,% Group B has WRITE access to A2. Cubes Dimensions Elements
Client A / Cube A Client B / Cube A Client AB / Cube A
Client AB has access to both Elements A1 and A2 i.e. element by element the highest privilege was picked.
Example 5: 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 data. Once combined, it is applying highest privileges, making the setup counterintuitive. Dimensions are kept simple and are out of this equations. Cubes Dimensions Elements
Client A: As per the setup, Client A has access to both Dimensions A and B and cubes A and B. Server explorer view:
Checking further:
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:
Checking further:
Conclusion: Client B does not have write access to any of the cubes. Client AB: As per the setup, Client A has access to both Dimensions A and B and cubes A and B. Server explorer view:
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.