One of the key security-related selling points within IBM Cognos TM1 is the tool’s ability to assign different security levels to different objects within the TM1 model for any given user or group. Properly handling object security interaction within a TM1 model can provide an unparalleled level of control over the system, user base, and data. As we have seen at many clients, it will improve the reliability of your data by ensuring that only the users qualified to change data at a given intersection point will be doing so, and allows for unique configurations by personalizing the security rights for each individual group. This added flexibility helps users get the most out of their TM1 model, so understanding exactly how it works is very important.
The security rights can be set up to gain the most control possible over what users can and cannot see, add, delete, or change. There are 4 different levels of object security which pertain to a user’s ability to manipulate data:
- Cube Security
- Dimension Security
- Element Security
- Cell Level Security
For the examples following, we will assume a single user is assigned to a single group. This way, when we talk about the ‘User’, we understand that this user is part of a TM1 security group. Let’s look at these different levels of object security in the simplest form. Say for example, a user is assigned READ access to a cube called ‘Planning Cube A’. If this is the sole security assignment, then the user will have READ access on all intersections of the cube. If a user is assigned READ access to a dimension called ‘Time’, then the user will have read access to all intersections involving the ‘Time’ dimension. Now let’s say that the only security assigned to a user is an Element level security on the ‘Time’ dimension. For example, the user is assigned READ access for the element ‘2015’ within the ‘Time’ dimension, which gives the user READ access ONLY to the element ‘2015’. The same concept applies to cell-level security.
Simple enough, right? Well, the tricky part lies within the way the security settings for these four different objects interact with each other when multiple levels of object security are assigned. Let us look at the example below:
You have a cube called ‘Planning Cube A’ with the following dimensions:
You assign a user READ access to the ‘Planning Cube A’ cube, but you also assign the same user WRITE access to all of the elements in this cube.
What do you think would happen in this example? In this case, the READ access of the cube will override the WRITE access of the elements, allowing the user to view the data within the cube but not allowing them to update any of the data.
Let us look at another example, assuming we are talking about the same cube with the same dimensions as the last example:
You assign a user WRITE access to the ‘Planning Cube A’ cube, WRITE access to all of the elements within all of the dimensions EXCEPT for the ‘Version’ dimension where you assign the user READ access to all of the elements within the ‘Version’ dimension.
In this case, the elements in the ‘Version’ dimension identify every intersection in the cube, and since the user is assigned READ access to all elements in this dimension, the user is unable to update data within the cube.
As stated by IBM, “When groups have security rights for a cube, those rights apply to all dimensions in the cube, unless you further restrict access for specific dimensions or elements”.
Why this type of interaction is useful
This type of object security interaction is essential for having a full level of control over your users and groups. By being able to set security access at different object levels, you are able to pinpoint and assign the security settings for a giver user exactly how you want them to be. Imagine this scenario, referring to the same cube/dimensions as the prior examples:
You wish to have all groups be able to view and read cube data for all territories specified in the ‘Territory’ dimension. You also want each group to be able to update cube data ONLY for their own territory and ONLY for ‘2015’.
By properly manipulating the different levels of object security, and utilizing the way they interact with each other, this can be accomplished quite easily with no coding and no additions to the security model.
To achieve this, we would take the following steps:
- Assign each Territory group WRITE access to the ‘Planning Cube A’ cube
- Assign each Territory group READ access to all territories (element level security) within the ‘Territory’ dimension that do not apply to that group
- For example, assign the ‘North’ territory group read access to all elements except for ‘North’ in the Territory dimension
- Assign each group READ access to all elements except for the ‘2015’ element in the year dimension (element level security)
With this security scheme set up, users will be able to view all cube data, but will only be able to update cube data related to the territories applicable to them.
While these are just a few examples of how the interaction between object security works, there are many great applications that can come out of fully understanding how the relationships work. In summary, if a cube has READ access specified for a group, then even if the elements or cells are specified as WRITE access, users in the group will not be able to update any cube data. However, if a cube is given WRITE access for a specified group, all of the dimensions by default take the access of the cube security assignments. It is in this way, a sort of top-down approach, that specific intersections and elements can be restricted for a particular group.