TM1 security overview

[Wim Gielis]

Hello all

Can I trick someone into this Friday afternoon Turbo Integrator exercise... It is just something I was thinking about, not entirely sure if it is (1) helpful, (2) feasible.

Let's create a 3D cube, containing dimensions:

1. TM1Object
2. TM1ClientGroup
3. Measures

Dimension 1 contains all cube names, dimension names, process names, chore names, application entry names. Appropriate suffixes need to be there to make element unique. The result is a rather large dimension.
Dimension 2 contains all security clients and security groups in 1 dimension. Same caveat as for dim 1.
The measures dimension contains 1 String element: 'Access'. It will be 'NONE', 'READ' or 'WRITE'.

The 3D cube is filled with TI by looping and doing CellGetS'es, basically, but also additional logic could be built in: a client can be read-only, a cube can be locked, and so on... Or we can use rules where approriate.

What do you think?

In vNext of the process, we could elaborate/refine if wanted. Someone's interested?

Wim

[lotsaram]

What's the purpose?

[Alan Kirk]

OK, I think I see where you're going with this; you want to make a one-stop shop for security. Or at least a lookup for security.

My concern would be with point (1), the helpful bit. The problem stems from the fact that the object security operates independently. Consequently you can have WRITE on the cube, and this is true enough. But if you're lacking any permissions on one of the dimensions of that cube, that won't get you anywhere. Consequently the "WRITE" cell value in the one stop cube is at best misleading. Alternatively if you set up the one stop cube so that it analysed any dependent security (so in this case it would make the Cube's security value "NONE" by virtue of the fact that the dim security was missing), that would be misleading as well as it would imply that the problem was with the cube security, when it isn't. Nor would it tell you exactly where the problem was (although I suppose that you could expand your measures dimension to hold a string element which does that).

(In this specific case I wouldn't bother; in my standard overnight process I just run one loop that checks that users have dimension access to any cubes that they have access to. However this is just a f'r instance.)

Also it doesn't cover the issue of element security, which is far and away the biggest piece of most security models and the most relevant one for determining access.

And there's the issue that in 9.5.2 at least, Application security seems to be flakier than your average Kellogs product.

A noble goal, but I'm not sure what/where it would get you in the end and consequently whether it would be worth the effort.

[Wim Gielis]

Thanks Alan, you definitely understood where I was going to.

I do realize now that doing "half" the job isn't very useful: a cube like that would only make sense for TI processes and chores I guess.
For cubes and dimensions, a lot more goes into the equation. And for Application security I also had issues in the past regarding security.

As to Lotsaram's post:
The most useful component of this exercise would be listing security by CLIENT instead of by GROUP, knowing that rights are additive in TM1.
Having an easy overview of security by client is definitely an advantage, since logging in ourselves and checking is way too time consuming in any decent TM1 model.

[declanr]

The most useful component of this exercise would be listing security by CLIENT instead of by GROUP, knowing that rights are additive in TM1.
Having an easy overview of security by client is definitely an advantage, since logging in ourselves and checking is way too time consuming in any decent TM1 model.

I have a TI that does this somewhere which I've used previously, it essentially cycles every security cube and creates another version all prefixed "}z_security_by_client_" and just swaps out the }groups dimension for }clients it also has measures that show:
1/ What security the user has
2/ A combined view of what builds it up e.g. ( WRITE:Group A:Group C, READ:Group B ) so that you can see whether taking them out of 1 group would still take away their access etc.

I will try and dig it out and post it over the weekend (including Monday since it's a bank holiday here.)

[Wim Gielis]

Hi Declan,

That would be interesting to have a look at!

Attached is the result of writing code this afternoon: 1 TI process and 1 cube (with 3 dimensions) with rules.
Drop the 6 files into a TM1 server, kick the server and run the TI process
The measure 'Access' is populated through rules and TI, the measure 'Access NEW' is the one that would be used in this cube (it's rules-calculated).
The cube will present an overview of security for processes and chores.

[lotsaram]

Hello all

Can I trick someone into this Friday afternoon Turbo Integrator exercise... It is just something I was thinking about, not entirely sure if it is (1) helpful, (2) feasible.

Let's create a 3D cube, containing dimensions:

1. TM1Object
2. TM1ClientGroup
3. Measures

Dimension 1 contains all cube names, dimension names, process names, chore names, application entry names. Appropriate suffixes need to be there to make element unique. The result is a rather large dimension.
Dimension 2 contains all security clients and security groups in 1 dimension. Same caveat as for dim 1.
The measures dimension contains 1 String element: 'Access'. It will be 'NONE', 'READ' or 'WRITE'.

The 3D cube is filled with TI by looping and doing CellGetS'es, basically, but also additional logic could be built in: a client can be read-only, a cube can be locked, and so on... Or we can use rules where approriate.

What do you think?

In vNext of the process, we could elaborate/refine if wanted. Someone's interested?

Wim

If you included an extra dimension for "object type" (cube,dimension,process,chore,application,element) then you wouldn't need any mucking around with prefixing element names in the monster dimension and the rules and TI process would thereby be that much cleaner. (You know multi-dimensionality and all!)

Compiling the TM1 Object dimension is only half the problem, the cube would be pretty difficult to navigate and would require a lot of automated subsets with good naming convention in the object dimension to make it at all navigable. I have something similar in my models but I have a separate cube by object type and include the clients dimension in order to do reporting on effective permissions there is a separate cube that reports on all element security across all dimensions that includes the dimensions dim as well. Element security aside, I think that it would be possible to do all the object security reporting in a single cube (with an object type dimension included) but I'm not sure I see the point or any advantage vs. separate cubes.

Rather than populating the security audit cube with TI rules is also possible. All you need is a copy of the groups dimension with an all groups total and the ConsolidatedMax function.