Administrator Guide - Part 4 – Kepion Support Center

Security Overview

Kepion supports data access and role-based security. Security can be defined for users and groups to limit their access to both data and application functionality. The following user types are supported.

AD users: Active Directory (AD) individuals from an AD system
AD groups: AD groups from an AD system
Role: A custom grouping of users within each application defined in Kepion

Each of the user types can be granted access to an application’s data model, such as read and read/write access to Models and Dimension Members.

Users or each user types can also be associated to System Roles which are predefined roles that grant access to functionality for a given application. For instance, the Designer role grants the user the ability to create and manage modeling objects on an application.

System Security Roles

There are five predefined security roles. These include System Administrator, Administrator, Model Designer, Report Designer, and Advanced Contributor.

The highest privileged role is the System Administrator which has unlimited access to all aspects of the system. This role can only be granted via the following:

Directly from the database:

Through the UI by another System Administrator who is logged on:

The rest of the system roles (Administrator, Model Designer, and Report Designer, and Advanced Contributor) are scoped by application. You can manage them within ADMINISTRATOR -> Security -> Membership.

Below is a summary of the privileges for each system role:

System Administrator: The System Administrator has the highest level of privilege across all applications managed by an installation of the Kepion system. System Administrator can create new applications and access all pages, including the Administrator page to add the initial set of users for a new application. System Administrator also has the ability to impersonate any user in the system. This System Administrator is scoped by the system.

Administrator: The Administrator role is given the privilege to manage both user security and workflow. For data security, this role can grant user access to models and dimension members. For workflow, this role manages workflow configuration such as user association to Contributor, Approver and Reviewer, Form and Rule associations and workflow filter groups. Administrators can also lock down plans to prevent additional data updates to the application. The Administrator role is scoped by the application.

Model Designer: The Model Designer role is given the privilege to manage the core modeling aspects of an application, including the ability to create new Dimensions, Hierarchies, and Models. The Model Designer role is also able to manage Forms, Rules, and Model variables, as well as being able to deploy OLAP databases to SSAS instances. The Model Designer role is scoped by the application.

Report Designer: The Report Designer role has the privilege to manage reports and report books for reporting. The Report Designer role is scoped by the application.

*This is a deprecated role that only applies to Kepion 2.0.

Advanced Contributor: Advanced Contributor role has the privilege to use advanced features, such as transactional drill-through, run rules on selected cells, and review user changes on Forms. The Advanced Contributor role is scoped by the application.

Below is a summary of the accessible modules of each role within Kepion:

Security Management

Navigate to the Manage Users & Groups node in the right-hand navigation pane. Here you will be able to manage all the users within an application. To add new users, groups, or roles to the application, click on the Add button.

In the Add User, Role or Group window, you can change the selection for Type from User or Group to Role to create different types of users on the application. By default, the User or Group is selected and will only allow valid AD user and AD group to be added to the application.

The following are actions that can be applied from the Manage Users & Groups module:

AD Sync: When AD groups are used in an application, the associated AD users for each of the AD groups will need to be periodically synced to match the relationship of users to groups within AD. It is recommended to perform AD Sync action by clicking on AD Sync whenever there are updates made to the underlying AD group/AD user association.

OLAP Deploy: Security settings on a SSAS application database are updated by clicking Deploy to OLAP button. Application security defining access to model and dimension members will be deployed to SSAS, allowing for the same security within the Kepion application to be reflected by third party client tools connecting to the OLAP database.

Role Based Security

You can associate users to roles by selecting the Membership node from the navigation pane.

Use the drop-down to select the current user to configure. Click on the Add to Role button to associate the current user to one or more roles. The Add Role window below will appear which you can use to pick the roles to associate the user to.

Data Access Security

You can define a user’s permission to access data by navigating to the Permissions node from the navigation pane.

With a particular user selected in the drop-down, you can define their permissions to access models with the below actions.

Dimension: When a user has access to a Model, the Dimension security will define additional restrictions on the data within that Model. The restrictions limit what data is visible to the user as defined by the Dimension security members.

Models: Grant read or read/write access to Models for the user.

Model Security Access

Users must be granted access to a Model to be able to view data from Forms and reports that are created off that Model. Users that are not granted this access will receive a connection error when they attempt to view these resources.

For single user, group, or role selection of the drop-down, you can grant access to Models by clicking on the Model button which opens up the Manage Models window.

Select the Models and the access privilege to add that permission to the selected user.

Dimensional Member Security Access

Dimension member security is defined in a restrictive manner. Should a user not have any Dimension Member security defined for a particular dimension, then they will by default have read access to all the members. However, once you define a restriction on a Dimension Member, only the members that have been granted either read or read/write will be accessible for the user.

Kepion supports adding dimension security with the following actions:

Single: Grant access for read or read/write to a single dimension member.
All (A): Grant access for read or read/write to a dimension member and all its descendants.
Children (C): Grant access for read or read/write to a dimension member and all its children.
Leaves (L): Grant access for read or read/write to the leaves of the dimension member.

Let’s explore the dimension member security by seeing how the following security settings affect the user’s security view. The graph belows shows a typical hierarchy.

For example, if we grant security to USA (A), with (A) representing All Descendants under a particular dimension member, then the user’s security view will be as follows:

If we were to instead grant the security as USA (C), with (C) representing the children under the USA node, then the user’s security view will be as follows:

Granting security to CA (C), with (C) representing the children under CA node will grant the user the following security view:

Finally, if we only grant security to the bottom leaf node of Lost Angeles, we will get the following security view:

Defining Member Access

To enable Dimension Member level security settings, you will need to first turn on the Security attribute of the dimension in the Modeler.

To define Dimension Member security, select the Permission node from the navigation pane and select a single user for the drop-down. Click on Dimension button which will open the window Member Access Security.

The Member Access Security window allows you to define member based security for either a dimension or a Parent-child (PC) hierarchy. By default, all members of a Dimension are given read and write access rights. However, once you start to define member security, only the members that are explicitly specified for read or read/write access will be granted access.

To define member based security, first select a dimension or a PC hierarchy in the drop-down, and then choose the READ-ONLY or READ/WRITE tab based on your need.

Tip: The corresponding region on the right side of the window will be highlighted by a yellow rectangle based on the permission tab you select.

Next, you can either double-click single members or check the member(s) in the hierarchy and use the icons (Single, Children, All, Leaves) in the ribbon to add the member(s) to the right side.

Security Inheritance

Users and AD groups can belong to one or more roles. So how does security get applied if a user belongs to multiple contexts as when they belong to multiple groups and roles?

Simply, a user’s permission is the union of all their associated permissions. The permissions are calculated by the union of the user’s own permissions with that of all the permissions of their roles and groups.

However, it is worth pointing out one interesting case: When there is no restriction on a dimension then it defaults to granting access to all members of the Dimension. Now imagine if we have two roles that a user belongs to:

One role called SuperUser which has no restriction on the geography dimension.
Another role called SeattleUser that has a write restriction to Dimension member Seattle.

Since the user inherits from both roles, the user gets a union of all their restrictions. Therefore, the user will be restricted to only Seattle for write even though the user belongs to the SuperUser role. That seems like a problem! However, the problem here is with the permission setting for the SuperUser role. The SuperUser role needs to be granted no restriction to the geography dimension explicitly. To do this we can use the special member All from the dimension hierarchy picker which will grant access down to all members of the dimension.

Note: In import, you can use the All member with no operator (or set to value 1) when specifying member security to explicitly grant all members access for a dimension. More information on import action can be found in the Security Import section.

Module Access Security

The Restriction feature is introduced to limit access to certain regions within the MODELER and ADMINISTRATOR module by user.

You can configure Restriction for a particular user or a user-defined role. When Restriction is applied to a user-defined role, all the users belong to that role will inherit the restricted regions. By default, Full Access is checked, meaning all regions under MODELER and ADMINISTRATOR are accessible (implicit all access).

To limit the access, simply click the Configure drop-down to select a user or role.

Then check the appropriate regions under MODELER or ADMINISTRATOR.

Click Save All at the top-right corner after the setup.

When navigating to the MODELER, the Demo user will only have access to the restricted regions.

Restriction Inheritance

How does Restriction security get applied if users belong to multiple contexts as when they belong to multiple groups and roles?

Restriction works similar to dimension security:

By default, Full Access is checked, meaning there is no restriction (implicit all access).
When inheriting from multiple roles, users will get the union of the explicit restrictions.

Now assume we have a user that belongs to two roles:

Model Designer (predefined system role) has no restriction specified. The default Full Access option is checked. (implicit all access)
Dimension Contributor (user-defined role) has explicit access to All Dimensions.

Since the user inherits from both roles, he/she gets a union of all the explicit restrictions. Therefore, the user only has access to All Dimensions within the MODELER module even though the user belongs to the Model Designer role (who is supposed to have access to all regions within the MODELER module).

Security Conclusion

Kepion supports out of the box a powerful security management system that both scales and allows for complex security setups – right down to dimension member access. Security can be managed via a friendly point and click user interface as well as quickly loaded via security XML import.