TM1 Forum

Need to bounce this off the group because I either had a misunderstanding about security or I've screwed up my implementation. I'm aware that TM1 security is additive, but how is it handled if a user is a member of several groups with conflicting assignments? Specifically, does TM1 keep groups separate when determining security for a given cell or is it additive within each dim/element w/o regard to cells?

An example:
If a user is a member of both groups, will TM1 allow the user write access to the BalanceSheet/Salaries cell? Unless I have an error in my configuration, it appears that TM1 is taking each dim separately. In this example, the user could write to BalanceSheet/Salaries even though a member exclusive to Group 1 or Group 2 could not.

Matt

mattgoff wrote:Need to bounce this off the group because I either had a misunderstanding about security or I've screwed up my implementation. I'm aware that TM1 security is additive, but how is it handled if a user is a member of several groups with conflicting assignments? Specifically, does TM1 keep groups separate when determining security for a given cell or is it additive within each dim/element w/o regard to cells?

An example:

Code: Select all

Dept Dim          Group 1    Group 2
--------------    -------    -------
Sales             READ       READ
BalanceSheet      READ       WRITE


Account Dim       Group 1    Group 2
--------------    -------    -------
Salaries          WRITE      READ
Payables          WRITE      WRITE

If a user is a member of both groups, will TM1 allow the user write access to the BalanceSheet/Salaries cell? Unless I have an error in my configuration, it appears that TM1 is taking each dim separately. In this example, the user could write to BalanceSheet/Salaries even though a member exclusive to Group 1 or Group 2 could not.

Matt

That's what I'd expect; the TM1 model is "least restrictive" as I understand it. So the member of both groups will pick up write access to Balance Sheet through their membership of Group 2 and to Salaries through their membership of Group 1. If a client has write access through any of the groups that they're a member of, it applies regardless of their membership of any other group.

A member of Group 1 alone will not have it because they have no write access to Balance Sheet.

A member of Group 2 alone will not have it because they have no write access to Salaries.

OK, that's what I'm seeing, so it was my understanding of the mechanism that was wrong. I had thought TM1 would evaluate each group separately and then apply security maximally but by group. Instead, it appears you're right that it combines element permissions within a dim for all member groups. I can work around it, but it does limit things.

Thanks,
Matt

There is a very little known and very poorly documented config setting (no surprises there) that may help you out SegregateCellSecurityByGroup=T (default is F)
This setting has the effect that only the security rights applied within each group as a distinct bucket are additive. It means that you need to apply the complete set of security rights within a group as opposed to assigning one group for element security of dimension X another group for cube access to cube Y, etc. This is generally a PITA and not that usefull but in certain circumstances it can be useful to give more granular security and yours might be one of those cases.

There is a very little known and very poorly documented config setting (no surprises there) that may help you out SegregateCellSecurityByGroup=T (default is F)

That's certainly a new one to me and very useful for some of the more annoying security models I've had to deal with, especially ones where I've tried to avoid cell level security.

Will give this a test in our environment - any idea what version this came into existance? Can't find any reference to it in any of the documentation although not the first time that situation would have occured

According to the "All config params per version" spreadsheet that was maintained by someone in TM1 engineering this setting has been around since 9.03

(my version of this very useful resource finishes at 9.5.1 so if anyone is able to swing a up-to-date copy my way with 9.5.2, 10.1 and 10.1.1 it would be nice )

Well how about that, I asketh and lotsaram giveth. After further consideration, though, you're absolutely right that this just creates a new set of problems with my security arrangement. I have a small number role-based groups that grant rights to sets of cubes (e.g. finance vs. accounting vs. HR) and then individual groups for each user to set rights to individual depts. If I enable this flag, I'd effectively need to merge cube rights into each user group. Obvious in retrospect that was I was trying to do wouldn't work since the rest of my security depended on cross-group rights. Sure would be nice if TM1 development could dispense with the secret flags, though....