GENERAL CONSIDERATIONS
Securing a planning application requires to consider 2 different aspects:
- User activities: which actions and components should a user or group of users perform. This is dealt with by creating user Roles.
- User data access profiles: what are the data elements that a particular user should be able to view or update. In relation to data, master data can also be either visible or hidden to a user. As an example, you may want to allow access to a particular entity from an organization to a user, but not necessarily giving them the ability to display the whole organization structure. This can be managed either in the Modeler, on a dimension/member basis, or alternatively, Please note that data access should first and foremost be managed inside the modeler, before considering Roles as an alternative.
In this article, we will NOT describe in detail all the aspects of security setup, but instead emphasize a few – not so well known – security setup options, such as:
- General but eventually not so obvious security behaviors to be aware of
- Preventing end-user from seeing all other members in a dimension where they only have access (read and/or write) to a subset of them
- What it takes to enable the ‘member on the fly’ option inside tables/stories
- Matrix security and its ability to Enable intercompany matching report through a specific security setup
- Designing security access based on member properties instead of member ID
- By exception, additional capabilities as well as Pro’s and Con’s of using Roles for member access definitions, versus using the modeler (which remains the default approach to security anyways). For example, in case of very large dimensions, improving master data processing time by configuring member access in roles instead of the modeler
General Security behaviors to be aware of
- When loading master data, security is being processed in the background, i.e. in order to speed the logon process, each user will have their member access rights updated according to the Read and Write property defined against each secured dimension. The larger the dimension, the more time consuming this may be as a result. It may be relevant to consider securing against nodes instead of securing at each leaf member level
- Inheritance of access rights applies in a top down approach: when you allow Read and / or Write access against a node, this implies propagating the setup against each node/leaf underneath. There is no need to do it at every leaf level in this case, which is also less efficient by the way.
- When dealing with multiple hierarchies, security is assessed against the dimension default hierarchy only. None of the other custom hierarchies will have an impact so always double check on the default one in case you wonder why such user can read or write data against some members.
Displaying a subset of a hierarchy so users do not get distracted by other parts for which they do not have access
- By default, when providing Read access (inside Roles configuration) to a dimension, granted users will be able to view every masterdata element from that dimension, even though they would be restricted to, as an example, only being able to Write data against one member.
- In case master data should also be restricted in terms of who can view master data elements (i.e. other members for which one may not have neither Read nor Write access), a specific option ‘Hide Parents’ needs to be turned ON at dimension level :
- By doing so, users having Write access to a leaf member will not be able to display any other member when navigating the dimension (like when setting a filter inside Stories).
Enabling the creation of members on the fly - ‘Add Member’ in the table widget in stories
Many customers are eager to provide flexibility to some LOB or Cost center owners by letting them add members to an existing dimension. However, they do not allow these users to create members against all dimensions but usually only a few of them (usually one only).
 |  |
In order to achieve this, you want to enable the ‘Maintain’ property for that or these specific dimensions within the Roles definition. If not checked, as an example, the dimensions below will not allow the ‘Add member’ feature.
On top of that, you also do not wish to let these users to create dimensions alongside nodes that are not in their scope of responsibility. In this case, you should also make sure that the ‘Hide Parents’ option described above is also turned on.
Roles and ability to secure member access by member property (not by member ID as in the modeler)
Users and Teams can be assigned to specific roles according to their profile.
A business user will typically be assigned a role being part of a Planning Standard license, whereas functional administrator will be assigned a role from the Planning Professional bucket, so that they can maintain models and more.
When entering a role configuration, one can define what applications components are accessible, such as running allocations, accessing public or private folders, using Value Driver Trees, etc…
Another aspect is about consumption of dimensions: this is an indirect way to give user access to a model. One will require a minimal Read access to each dimension of a model in order to being able to access it. Then, beyond that, refined member security is accessible by enabling Security (Data Access Control) on a dimension per dimension basis, within the modeler:
Enabling this option will open 2 additional fields on a dimension master data, for Read and / or Write access, to which you can assign Users or Teams. This means data access is defined at member level, based on member ID’s.
However, in some cases, a functional administrator will require more flexibility or even a different approach to securing data access. As an example, especially when dealing with large dimensions, one may want to provide access to some members based on a more generic approach, without assigning users to individual members. If you would consider assigning data access based on a member property value (e.g. allowing data Read or Write to Entities where a ‘Region’ property was set to ‘EMEA’), you want to consider using extended security within Roles :
Then, on a model per model basis, you can define in a generic way, which data access is granted by using advanced filters:
Remarks:
- This approach is very modular and allows to combine several criteria allowing to make a security design less time consuming as there is no need to access the modeler security properties, even when new members are added.
- It is less error prone as Security is designed with a systematic approach
- However, this will require to create a different Role for every group of users that require an equivalent access
Generally speaking, this approach, beyond its functional benefits, is mostly designed at security implementations with large dimensions and/or a fairly limited number of groups of users requiring access to a specific data region.
Roles versus Modeler security for member access: Use case / pro’s and con’s
With the approach described above, you can eventually setup member security within roles which, at the end of the day, fulfills an equivalent objective to assigning Read and/or Write permissions in the modeler.
Why and how would you do this?
As a matter of fact, maintaining a dimension (even more when it is a secured one) is consuming system resources. First of all, there are several validation checks taking place, as well as hierarchy updates to be performed. Moreover, secured dimensions require their own processing: users are validated against members with some caching operations taking place behind the scenes. Now, if you imagine an extra-large dimension, there can be a fairly significant amount of time dedicated to this security caching process.
An alternative can be that, instead of processing all user security against a secured dimension at dimension saving time, you would rather skip that step completely and replace it by an ‘on the fly’ security validation at query time (when stories are refreshed). This can be achieved by securing a dimension in roles.
However, one could react that such a design could lead to a growing number of roles which could generate a maintenance burden.
There is a simple answer to this: let’s take a look at one function in Role security called ‘IS_ACTIVE_USER’.
By using this function, you can actually point to any property from a secured dimension and read from it which user has Read and/or Write access to a member:
In the example above, the Entity dimension has a property called ‘Security’ (the property name can be anything). This property values will list every user having access to members. Example:
| Member ID | Security |
| EMEA | UserA |
| FRANCE | UserB, UserC |
Therefore, a single role (e.g. ‘Planner Reporter’) could be sufficient. Then, within this role, by using the function illustrated above, you could do 2 things that you would not have immediately thought of:
- Perform on the fly member access security, therefore speeding up your dimension processing
- With a limited set of roles, define, inside the dimension/modeler which user has access to which member.
Pro’s and con’s of this approach to security:
| Pro's | Con's |
| Speeds up processing/saving time of large/secured dimensions | May come at a cost when opening/refreshing stories |
| Allows Roles/Member access against Public Dimensions to be reused across models | Likewise any property, the custom ‘security’ field is limited to 127 characters (usually not an issue) |
Matrix security and the specific case of Intercompany matching reports
Intercompany matching is some kind of a special activity, especially with regards to member access rights. As a matter of fact, in order to effectively match your intercompany numbers, one must not only review how much they booked against their trading partners, but also be able to review what these other partners booked against them. Obviously, one may only be able to view the intercompany amounts coming from trading partners with them, without being able to see all the other data (such as their counterparts’ intercompany amounts towards other partners, nor even non intercompany data nor anything else).
In order to achieve this, you want to enable roles security as illustrated in the example below (considering that the running user is responsible for the entity ‘ENT0002’):
Self Service security
In order to ease security maintenance, end-users can Request to leverage Roles that have been pre-configured as ‘Self Service’.
When end users are making such a request, a dedicated workflow will be triggered so that either the Manager (from the User security definition page) or another user (defined at the time when a Role with Self-Service option is saved) will be asked to approve or reject it.
A notification is triggered and all pending requests that one is receiving are available for review under Security / Requests.
CONCLUSION
Hopefully, this article gives you several insights as to numerous Security configuration options and advanced customizations.
USEFUL LINKS
- Introducing SAP Analytics Cloud for Planning
- SAP Analytics Cloud Learning Tracks
- SAP analytics Cloud Webinars
- SAP Analytics Cloud for Planning Community
- SAP Analytics Cloud help - Security
This blog is part of the Best Practice series. If you want to discover more best practices, please check out these blogs as well:
https://community.sap.com/search/?ct=blog&mt=819703369010316911100650199149950&q=%23best_practices
- SAP Managed Tags:
9 Comments
