Security in TM1 is one of those things that can make a TM1 administrator go crazy with overlapping or new requirements and users who, for whatever reason, cannot do what they are expecting to be able to do. For some reason, things don’t get better reading the documentation, which sometimes seems convoluted and doesn’t answer the key questions most admins have.
In the following post, TM1 security is peeled back layer-by-layer. Starting from the very basics of cube security, and then finishing with a multi-layer multi-group security setup.
First, let’s start our discussion on TM1 security with an excerpt from the documentation describing the different access privileges. Primarily, this is to ensure 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 another 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 another 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
As an illustration, the following TM1 model is 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. In summary, 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 a per-group basis, not on a per-user basis. However, 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 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. 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.
TM1 Security Privileges – Relationships Within One Group
It is important to mention that security privileges within one group might be overlapping. For instance, the security for a data cell (an intersection of elements) can be defined by cube, dimension, element and cell security at the same time. Therefore, 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.
In another case, 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. The user can view cube data, but, they cannot update the cube data. Let’s reverse the scenario given. For example, a user has WRITE access to a cube and READ access to the elements of this cube. The READ access still applies. 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 |
 |  |   |
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 the dimension security, in the next setup the element security is switched around:
| Cubes | Dimensions | Elements |
 |  |  |
To illustrate, Cube A is the same as in the previous iteration with the writeable cell shift that reflects the element security changes. However, Cube B is still READ despite the fact that Element A1 / Element B1 is specified as WRITE. In brief, 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.
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. After that, 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 from the highest-then-lowest way:
- Combining group privileges first – applying the highest privileges.
- 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.
Sample data:
| 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 |
 |  |   |
| 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 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 the highest privileges, making the resulting setup counterintuitive. Dimensions are kept as WRITE and; as we already know, the dimensions are out of this equation.
| 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 the Cubes A and Cube B setup 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 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: Checking further: Conclusion: Neither Group A nor Group B has 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 counter-intuitive but valid result – Cubes A and C are writeable.
Element Level Security
Element level security is where we assign specific security to individual elements in a TM1 dimension and is what we did in a number of the examples above. We have a separate blog post that details how to apply element level security right through a very large dimension. The post is Cascading Element Level Security in TM1. It details how you can use a TI to apply read and write security to different groups of users at all levels of a large dimension.
Cell Security
Specific cells can also be secured in TM1. This can be a time consuming and complex task that can dramatically degrade the performance of your model. There is definitely a right way to do it. We have a best practice guide to Cell Security available here that we encourage you to read if this is a path you need to take.