Performance Modeler and security

[RonLat]

There is a cube with three dimensions Dim_A, Dim_B and Dim_C.

• In the first step the CubeSecurity is set for a certain group to READ.

• The DimensionSecurity is set for the same group to READ.

• The user belonging to this group can read the view of the cube.

• In the next step a right click on the Dim_A and selection of the menu for ElementSecurity_Dim_A.

• Without changing anything further the user cannot read the standard view of this cube anymore.

• It takes the setting of READ or WRITE to at least one element in all the cube dimensions for the user to be able to read the cube view again.

• If all the elements of the cube dimension are set back to NONE, the user can’t read the view of the cube.

Is it necessary to set explicitly the ElementSecurity in all elements of the cube dimensions after clicking on that menu? Why can’t I simply set the CubeSecurity for a group to READ and leave it by that?

[declanr]

If you create an element security cube for any dimension then the default assumption is that every group has no access to an element unless you specify otherwise.

If you have a multi group environment we normally get around this by having 1 or 2 base groups in addition to the more detailed groups. E.g a base group would be “All Planners” and then the detailed group is “Planners with Write access to Austria”.
Your base group gets all the high level access and possibly read access to all countries but then the detailed group just gives that little bit of extra access they need.

If element security is not needed for a dimension then don’t create the security cube. Element Security cubes should only be created if you need to split security at that level.

[RonLat]

I’m not sure if I understand you right. Once the CubeSecurity is set and I don’t need the element security, should the hidden object }CubeSecurity be deleted?
What is with the objects }DimensionSecurity, }ElementSecurity_Dim_A, }ElementSecurity_Dim_B, }ElementSecurity_Dim_C? Should they be also deleted?

[lotsaram]

I’m not sure if I understand you right. Once the CubeSecurity is set and I don’t need the element security, should the hidden object }CubeSecurity be deleted?
What is with the objects }DimensionSecurity, }ElementSecurity_Dim_A, }ElementSecurity_Dim_B, }ElementSecurity_Dim_C? Should they be also deleted?

I suggest you first read the administration guide and start by getting a solid understanding of how TM1 security works. Otherwise it is going to be really difficult for you to understand any advice from folks like declanr or myself. Personally I'm more than happy to try and answer specific questions to a concrete business case, but it isn't our job here to explain basic concepts (and actually it isn't our "job" at all).

Some basic points:

• If you delete the hidden }CellSecurity cube then you are removing the cess security. The hidden cube IS the cell security.

• Cell security and element security are independent but they do work together to give a combined result. Think of element security dictating which elements a group can see, and then if the elements can be seen whether there is read or write access.

• Cell security can only lower or raise element security. That is it can promote read to write or demote write to read. But if there is no access through element security then cell security is powerless to do anything about it.

• Both cell security and element security cannot trump cube security. If a group has only read access at cube level then they can't write to the cube. Period.

I could go on but that might get you started. HTH.

[tomok]

TM1 works in this order:

1. Cube security

• Dimension security

• Element security

You can't skip a level on the way down. If you have none of these cubes then all users can WRITE to every cube. If you enable cube security, and nothing else, users will get the rights to the cubes per their group membership, for every part of the cube. Once you enable cube security then you will need to specifically assign security for every cube. If you enable dimension security then users will need at least READ to each dimension that exists in the cubes they use in order to READ data from the cube. If they need to WRITE then they will need WRITE to every dimension in the cube. Once you establish dimension security you will need to specifically assign security to every dimension. If you enable element security for a dimension then users will need to be specifically given either READ or WRITE to every element that they need to interact with. You do not need to establish element security for every dimension. It is optional. However, if you do not then the default security setting is WRITE for that element.

Security in TM1 is additive, meaning you get the sum of the rights of all the groups you are a member of. You also get the highest rights if there is a conflict. If one group you are in has WRITE to a cube and another has READ you will get WRITE. This is true for dimension security and element security.
The other thing you need to know is when you cascade down from cube to dimension to element security then the group needs WRITE all the way down in order to actually WRITE to the cube. If you give out WRITE to the cube, but READ to at least one of the dimensions in the cube then the user will receive READ. Same thing for element security.

If you are a TM1 admin I recommend you establish a test server and play with these concepts to see for yourself how they work. Once you figure it out it will become second nature. Also, I have not mentioned Cell Security cubes (which potentially trump all other security settings for a specific cube) because you don't have any.

[RonLat]

Thank you all!

I think I understood the basics. I also solved my little problem by simply deleting the hidden cubes

}ElementSecurity_Dim_A
}ElementSecurity_Dim_B
}ElementSecurity_Dim_C

Now the users in the group have access again.

[tomok]

Thank you all!

I think I understood the basics. I also solved my little problem by simply deleting the hidden cubes

}ElementSecurity_Dim_A
}ElementSecurity_Dim_B
}ElementSecurity_Dim_C

Now the users in the group have access again.

When it comes to security you must be careful of the actions you take as an Admin as it can have serious repercussions. You don't click around looking for the security settings. For example, if you right-click on a dimension in the explorer tree and then choose Security, Element Security Assignments you are not just reviewing the element security for that dimension, you are creating an element security cube itself and now no one is going to be able to see the elements in that dimension until you go in and assign the rights. If you are wanting to review the security for TM1 it is better to review the actual hidden security cubes than to right-click on any object in the server tree and choose a security option from the menu.