I’ve been tweaking a few security models in PA recently, so it’s a good opportunity to jot down some thoughts. Here’s a list of ideas in no particular order.
First of security is very boring and quite hard to test & verify, so it often gets overlooked. You need an ability to ‘see’ things as a user and PAW has no built-in impersonation feature (although there’s a REST API call for it, so it’s possible), so having a few dummy accounts you can login to is a must. A simple process of copying groups from a target user to a dummy user is very helpful.
I usually separate secuirty groups in TM1 into 2 categories:
This split allows you to keep security definitions contextually split and you can sync the type 1 groups between different environments, whereas type 2 groups are environment specific.
PAW groups usually map quite nicely to ‘application’ or ‘functional’ ones, as they define books that people have access to. So you have ‘Revenue forecasting’ PAW group that will translate into a set of ‘what objects should they see in TM1’ group. Syncing PAW groups to TM1 streamlines this step (still waiting for PAW security API, sigh).
I try to keep number of groups in TM1 to some reasonable amount, so if I’m looking at a design that entails thousands of groups, I’m starting to question whether it’s easier to pivot it around and have a group by user and assign security that way. A large number of groups makes everything security related slow(er), so it’s better to keep it low. If you end up with groups by user approach – include a process to delete old groups as they will accumulate.
You should try to have a group per some entity (cost centre, project) and avoid creating combination groups, like CC_X_Account_Y – that’s usually a sign of some odd assumptions.
I still run into ‘Cell security rules make things slow’ concept every now and then. Overall CellSecurity make things slow in 2 cases:
['Revenue forecasting']=S:...
) will make the rules very specific and fast.I try to avoid SecurityRefresh as much as I can, especially if there’s a chance it’ll be ran during the normal hours (e.g. users assigning security). SecurityRefresh is a global locking operation (it’s quite bad when the system takes an unexpected breather for all users without any clear reason - it erodes trust) and it will get slower over time, so having a system without it just alleviates the need ot think about it.
The common reasons for needing a SecurityRefresh
:
An alternative approach (only if you really need refreshes during the day), can be to create a cube that would calculate the required changes (including removals) and use it a source for applying security.
Using }ClientGroups
as an example, you’d create a
ClientGroupsDetectChanges
with dimensions like:
And then a TI using Apply changes
measure as source to AssignClientToGroup
or RemoveClientFromGroup
I haven’t used SecurityOverlays until a recent project, where they were used to improve CellSecurity performance. Overlays were used to define security on some dimensions and therefore allow a reduced number of dimensions in CellSecurity. Rewriting those CellSecurity rules made it Overlays redundant, so we removed the overlays :)
I do see the potential use cases for Overlays, but it’s adding another thing to think of in regards to security and it’s hard enough as it is in most cases.
I had a lot of fun with DataReservation functions on every model that was using TM1 Applications / Contributor and never had a use for it outside of TM1 Applications. Despite most people thinking that they need ’exclusive’ access to data, they almost never do and having it creates an extra layer of complexity whilst transferring data ownership (e.g. handling people being on leave, last minute changes, etc). Having a transaction log is enough to trace ‘who changed my data’ in most cases. This opens up a whole ‘how complicated your worklow really needs to be’ topic, but this post is way too long already :)