TM1 Admin Right Restriction

Post Reply
sleoni72
Posts: 2
Joined: Tue Nov 10, 2015 1:36 pm
OLAP Product: TM1
Version: 10.2.2
Excel Version: Excel 2013

TM1 Admin Right Restriction

Post by sleoni72 »

Hi,

I am currently struggling with a customer request as follows :

. a Payroll Application has been built with 3 specific cubes which are populated with TurboIntegrator processes and which contain rules for automatic calculations of Payroll Components.
. since the Cubes contain confidential information, the TM1 ADMIN, DataAdmin and SecurityAdmin Groups are to be restricted and should not see any data in the 3 Payroll Cubes
. however, the ADMIN role should still be able to edit the TI Processes and Cube Rules if this would be required.

Basically, the question is how can a User from an Admin Group in TM1 be restricted from seeing any data - by default, by being a user of an Admin Group it means you have all Admin Rights including Read/Write Access to Data.

Assigning the TM1 User (in this case the TM1 Administrator who maintains the overall TM1 environment) to a 'normal' User Group enables to restrict access to data. However, in this case, that user can only read and execute TI Processes. Editing of TI's/Rules is possible BUT saving the changes is not possible.

To my opinion, the only way is creating a new TM1 Payroll Instance where the ADMIN role is assigned to another person (let's say the Payroll Super User) and the real TM1 Administrator (i.e. the User who maintains the overall TM1 environment) is not a user within that separate Payroll Instance.

Please advise me if this would be the only solution since I was hoping the TM1 Security within the same instance would be able to deal with this - I assume that this request is not so exotic, especially lately where TM1 Applications are subject to GDPR and TM1 Admin Users are to be restricted from accessing Personal-related data.

Looking forward to any reactions ...
Wim Gielis
MVP
Posts: 3103
Joined: Mon Dec 29, 2008 6:26 pm
OLAP Product: TM1, Jedox
Version: PAL 2.0.9.18
Excel Version: Microsoft 365
Location: Brussels, Belgium
Contact:

Re: TM1 Admin Right Restriction

Post by Wim Gielis »

Hello Stefan,

To me, unless I miss something, this is also the only way to implement this. Admin means everything.
Maybe data reservations or security overlays could be an option but that's not obvious and needs to be looked at. I have no ready-made answer.

If it's a different TM1 model, you would also lock access to the data directory of the other instance, and other access to files in general, for example.
And use a password that goes beyond 'apple' or any other obvious choice or pattern (like username - password is 'first name - first name')
If data comes back to the main model, it should be done in such a way that for example salaries are not visible (like in, you see as an admin person the salary costs of an entire department by functional role, but there's only 1 person with that functional role working in the said department).

Best regards,

Wim
Best regards,

Wim Gielis

IBM Champion 2024
Excel Most Valuable Professional, 2011-2014
https://www.wimgielis.com ==> 121 TM1 articles and a lot of custom code
Newest blog article: Deleting elements quickly
sleoni72
Posts: 2
Joined: Tue Nov 10, 2015 1:36 pm
OLAP Product: TM1
Version: 10.2.2
Excel Version: Excel 2013

Re: TM1 Admin Right Restriction

Post by sleoni72 »

Hi Wim,

good to hear you again on the forum here - I do agree with your additional comment that a separate environment would also require limited access to the TM1 Data Directory and other directories. Also, in the separate instance for Payroll, then ADMIN LogOn will have to have a dedicated password.

As you also state, the resulting calculations will need to be transferred at later stage to a P&L Cube within the broader application, so the transfer process will have to generate ASCII Output Files from the Payroll Instance to be imported to the Main Instance in such a way that the level of detail does not give way to what is considered as too confidential (e.g. 1 person in 1 single cost center).

Thanks for your reply, and definitely it confirms my initial concern that only a separate TM1 instance could resolve this request.

As per statement of a colleague consultant, I guess it would make sense that IBM would come up with a new upgrade feature of TM1 where the admin would be able to access all the objects but where data would be automatically encrypted for such profile (credit to Xavier VDL for this).
Wim Gielis
MVP
Posts: 3103
Joined: Mon Dec 29, 2008 6:26 pm
OLAP Product: TM1, Jedox
Version: PAL 2.0.9.18
Excel Version: Microsoft 365
Location: Brussels, Belgium
Contact:

Re: TM1 Admin Right Restriction

Post by Wim Gielis »

sleoni72 wrote: Thu Mar 22, 2018 12:43 pmAs per statement of a colleague consultant, I guess it would make sense that IBM would come up with a new upgrade feature of TM1 where the admin would be able to access all the objects but where data would be automatically encrypted for such profile (credit to Xavier VDL for this).
Maybe a fourth category:

- Admin
- SecurityAdmin
- DataAdmin
- Admin with limited data access

Just thinking out loudly.
Best regards,

Wim Gielis

IBM Champion 2024
Excel Most Valuable Professional, 2011-2014
https://www.wimgielis.com ==> 121 TM1 articles and a lot of custom code
Newest blog article: Deleting elements quickly
foogy
Posts: 37
Joined: Fri Nov 16, 2012 5:44 pm
OLAP Product: TM1
Version: 10.2.2 FP6
Excel Version: 2016
Location: Germany

Re: TM1 Admin Right Restriction

Post by foogy »

sleoni72 wrote: Thu Mar 22, 2018 12:43 pm Thanks for your reply, and definitely it confirms my initial concern that only a separate TM1 instance could resolve this request.
Hi sloeni72,

I now find myself in exactly the same situation, need to prevent access to confidential data from other Admin users and my considerations came to the same conclusion, i.e. having a separate TM1 model for that purpose with very limited access, and some further impacts related to that approach:
  • Protection required on file level as well
  • Even a different service user should run the confidential TM1 service, as current service user credentials are part of documentation of "normal" environment
  • Real-time calculation into GL accounts for personnell costs or into PNL of main application not possible due to required file transfer
  • All support requests will hit the one administrator of the confidential model, colleagues cannot support here (by the way this is my main concern)
  • Significant portion of total effort for this HR module goes into those extra measures, without adding value from a functional point of view
Would you mind to share your experience? How did you finally approach this requirement? Any suggestions and recommendations, lessons learned?

Thanks a lot!
User avatar
Elessar
Community Contributor
Posts: 331
Joined: Mon Nov 21, 2011 12:33 pm
OLAP Product: PA 2
Version: 2.0.9
Excel Version: 2016
Contact:

Re: TM1 Admin Right Restriction

Post by Elessar »

Hi,
  • "Real-time calculation into GL accounts for personnell costs or into PNL of main application not possible due to required file transfer": you can make a "near real-time calculation" by using a TI process (datasource=ODBO) ran by User, or you can use REST API to transfer data
  • "All support requests will hit the one administrator of the confidential model, colleagues cannot support here": for support requests like "Explain the value in this cell" - yes. But if you have a request to change the code, you can have an "HR_Dev" server with obfuscated data so that other developers can participate. And yes, the HR_Admin will have to move from "HR_Dev" to "HR_Prod" server
Best regards, Alexander Dvoynev

TM1 and Data Science blog: 6th article - PAfE + VBA: Commit each cell without pressing “Commit” button.
User avatar
ykud
MVP
Posts: 148
Joined: Sat Jan 10, 2009 10:52 am
Contact:

Re: TM1 Admin Right Restriction

Post by ykud »

I did this once with a separate tm1 model that ran on a separate / isolated server that had file system level encryption and a different set of OS user accounts.
Data was transferred to the main model using file transfer, but files were PGP encrypted. HR server would export the encrypted files to the target server and kick off runTI to decrypt & ingest them.

It was before data encryption was supported in Tm1, so built-in encryption might be a better choice of doing it now. The challenge I see with encryption is that you'd need to change the way you promote changes, file copy & restart wouldn't work anymore. Using Git would solve this though, as well as allow looking into the rules / TI code without seeing data, I think it might be a good area to investigate.

Re DEV_HR servers -- there's some undocumented data obfuscation capability ( http://feederwhisperer.blogspot.com/201 ... -your.html ) that should allow you to copy prod to dev without exposing anything of value.

Cheers
Post Reply