Xcelerate Security

One of the more common questions we get both during and after an Xcelerate implementation is “How does Xcelerate Security work”?  Xcelerate’s security is not complicated; however, there are multiple elements to it.

The following diagram provides an illustrative overview of the different Xcelerate security elements.  Each is described in further detail below.

Overview

Xcelerate Security can divided into 6 layers, 3 External [to Xcelerate] and 3 Internal.  The External [to Xcelerate] requirements are self-explanatory, but I will go into further detail on the functionality and integration available with the Internal Requirements.

External Requirements:

• Users must have an account on the Domain
• Users must be a member of the Xcelerate MSAD Group
• Users must have the Xcelerate Excel Add-In Installed

Internal Requirements:

• Menu Security: To see the Xcelerate menu, users must be assigned access to specific reports / worksheets / folders
• Hierarchy Security (Permission): To be able to run a report / worksheet, user must be assigned access to members of a hierarchy
• GL Security (Optional): To see results on the report / worksheet, users must be granted access to specific GL Strings

Each of these External requirements work together to provide a robust and very inclusive security solutions:

Menu Security

In organizations, not all worksheets and reports should be visible to all users. Menu Security enables administrators to restrict users’ access to specific worksheets and reports. Once Xcelerate is installed, the list of worksheets and reports that users have access will be available under xcelerate tab. With Menu Security, the administrator can restrict users’ permission to both relational and OLAP worksheets and reports. When users are moved from one group to another, their access rights will change depends on the permission of the new group.

Hierarchy Security (Permissions)

To both improve the user experience and restrict end-users from viewing data they are not permitted to see, Xcelerate’s Hierarchy Security functionality filters the available options in the report and worksheet user selections.  This feature enables administrators to define user or group permissions to the OLAP Cube dimension members.  Unlike Menu Security however, Hierarchy Security is not able to restrict a users’ access to a relational user selection. In other words, if a user selection is built as a relational type, hierarchy security is not applied.  For this reason, it is recommended that any dimension which will have hierarchy security enabled should be build as an OLAP type.  Important note: Relational Reports definitely can be built using OLAP user selections.  It is actually more of an exception to have relational user selections in a report or worksheet, so this issue really is only a concern when client specific customizations are implemented which require a relational user selection.

GL Security

At many firms restricting access in the user select (e.g. to a set of specific Offices and/or Departments) is enough to satisfy their security requirements as users are only able to open reports and worksheets for the Offices they have access to.  Some firms however have a more complex security requirement where it is really the combination of multiple dimensions within the cube that define the sets of data available to a user.  For example, a user has access to Office 100 and 200, but in Office 200 they are not able to open Department 120.  With Hierarchy Security we are not able to restrict the Department selection based on the Office selection, so since the user needs access to Department 120 in for Office 100, they would need to continue to be able to see Department 120 in the Department user selection.  In these situations, we need to use GL Security to restrict the resulting data being returned to the report or worksheet.

 GL Security Requirement example

 User A can access Department 101 in either Office 100 or 200, but is only able to access Department 120 in Office 100.  They should not be able to see data in Department 120 for Office 200.

GL Security enables administrators to controls users’ permission on retrieving data from the system using a combination of segments / dimensions.  Using the above example, the functionality allows us define security using the combined members of both the Office and Department (e.g. 100-120 security can be different then 200-120 security).

GL Security is unable however to restrict data retrieval in relational reports. Although OLAP user selections Hierarchy Security is still applied on relational reports, the GL Security is not.  In other words, all users who can run a report for a set of user selections will be returned the same results regardless of their GL Security.  Using the example above, if User A runs a relational report for Office 200, Department 120 they will be returned results.

Important Notes:

• GL Security is enabled on OLAP Reports and Worksheets by default – however it can be disabled
• Hierarchy Security is not enabled by default on Reports and Worksheets and needs to be enabled for each Reports and Worksheet through the Security pages of the Xcelerate Administrator Portal.

If you still have any questions regarding Xcelerate security please do not hesitate to reach out to us and ask any questions.