Going through a security set up for a project now with Planning Analytics Workspace as front-end and thought I’d share how we set up PaW & PA security in hte last few ‘largish’ deployments, i.e. with

• multiple TM1 servers
• multiple development teams

maybe there’s a better way out there, please let me know?

Some background

• Planning Analytics Workspace (PaW) has a security model that is not connected to TM1 groups
• PaW security defines what books / folders users are seeing on login
• PaW security has no automation hooks, only the ability to import / export current user & group definition from a file
• Multiple teams shouldn’t have Administrator capability in PaW in production
• Security maintenance should be centralised for auditing / compliance reasons

The question is how we grant users access to Planning Analytics (with PaW as front-end) in a robust fashion without making all developers admin everywhere?

The approach we use

• PaW is the main source of security (list of users & groups) on a fairly high level (level of book access), i.e. we would have a Server A XYZ Application user group to define access to Application XYZ books in PaW.
• Each TM1 server defines a finer level of security (i.e. access to a specific dimension elements or cube security for a users in XYZ Application group). As an aside: I’m a big fan of splitting security definition in 2 sets of groups:
  • application groups that define the object security (i.e. what cubes / dimensions / processes) members can see, for example OPEX application
  • data groups that define the element security for dimensions, for example Cost Centre N
• Users are added in PaW and assigned to “application groups” by central PaW admin
• After adding users / groups PaW admin exports the list of users and groups to a shared location.
• Each Tm1 instance reads this export on schedule and ‘filters’ only the groups & users to be added for this server, adds and assigns the user groups. Here’s a sample of a TI that uploads the file

Something like this:

This approach has the following benefits:

• Centralised user access maintenance
• A reasonable compromise between level of security granted in PaW (i.e. access to Opex application) and a more detail group assignment in TM1 (access to cost centre N)
• Adding / removing users from PaW will sync to all related Tm1 models as long as the updated security definition is exported from PaW

And following drawbacks:

• Manual security assignment in PaW, here’s to hoping for an API.

PS: the cat picture is generated by Stable Diffusion, I’m not running out of cat pictures ever again.