Data Access Profile Setup

You must define a data access profile for all secured dimensions of a model.

If no profile is defined for a secured dimension, the users assigned to the profile do not have access rights to that model. If you partially define access, for example, for one of two secured dimensions, users are still denied access to the model.

After creating a data access profile, you assign it to users as needed.

Features

General Rules for Data Access Security

Data access security is based on the following rules:

By default, no one other than the system administrator has access to members. Member access must be explicitly granted.
A user can be assigned data access individually and through team membership.
Data access privileges flow down the hierarchy, from parent to child.
When in conflict, the least restrictive data access profile is applied.
In case of a conflict between individual and team data access, the least restrictive setting is applied.

Creating Data Access Profiles

Go to the Administration page and under the Security section, choose Data Access Profile.
On the screen that appears, choose New.
Enter the ID and description of the new data access profile.
Select the required model from the list.
For each authorization relevant dimension, select the required members and set their access rights.
Go to the Users or Teams tab to assign the new data access profile to users that are assigned to the current environment or teams that have corresponding users assigned to it.

Defining Access to Members with Children

When defining access to a secured dimension that has one or more defined hierarchies, security is applied to the member and all of its children. For example, if you grant access to a member that has 10 children, users with access to the parent member also have access to the 10 children.

You can restrict a child member of a parent with ‘Read Only’ or ‘Write’ access by creating a separate data access profile and assigning the child ‘Denied’ access. Alternatively, you can use the same data access profile as the parent, but create a new line item for the child.

Resolving Data Access Profile Conflicts

Since you can define member access by individual users and by teams, there may be situations in which conflicts occur. The following sections describe some potential member access conflict scenarios and the rules the system applies to resolve those conflicts. These scenarios are based on the assumption that the Entity dimension is a secured dimension and has the following hierarchical structure:

Hierarchy	Members
H1	WorldWide1	Sales	SalesAsia	SalesKorea SalesJapan ESalesAsia
			SalesEurope	SalesItaly SalesFrance ESalesEurope
H2	WorldWide2	Asia	Korea	SalesKorea
			Japan	SalesJapan
			eAsia	ESalesAsia
		Europe	Italy	SalesItaly
			France	SalesFrance
			eEurope	ESalesEurope

Conflict Between Profiles

When there is a conflict between data access profiles, the least restrictive profile is always applied. This section describes three different scenarios where there are conflicts between profiles.

Example

Scenario 1:

User1 belongs to Team1 and Team2.
There are two data access profiles: ProfileA and ProfileB.
ProfileA is assigned to Team1 and ProfileB is assigned to Team2.

The data access profiles are described in the following table:

Data Access Profile	Access	Dimension	Member
ProfileA	Write	Entity	Sales
ProfileB	Read Only	Entity	SalesAsia

In this case, the least restrictive profile between the two, ProfileA (Write), is applied. As a result, ProfileB is ignored by the system, and User1 is able to send data to both SalesKorea and SalesItaly.

Example

Scenario 2:

User1 belongs to Team1 and Team2
There are two data access profiles: ProfileA and ProfileB.
ProfileA is assigned to Team1 and ProfileB is assigned to Team2.

The data access profiles are described in the following table:

Data Access Profile	Access	Dimension	Member
ProfileA	Read Only	Entity	Sales
ProfileB	Write	Entity	SalesAsia

In this case, the least restrictive profile between the two, ProfileB (Write), is applied for the child members of SalesAsia. As a result, ProfileA is ignored by the system, and User1 is able to send data to SalesKorea, but not to SalesItaly.

Example

Scenario 3:

User1 does not belong to any team.
There are two data access profiles: ProfileA and ProfileB.
Both the profiles are assigned to the user.

The data access profiles are described in the following table:

Data Access Profile	Access	Dimension	Member
ProfileA	Denied	Entity	SalesAsia
ProfileB	Read Only	Entity	Sales

In this case, the least restrictive profile between the two, ProfileB (Read Only), is applied. As a result, ProfileA is ignored by the system, and User1 is able to retrieve data from both SalesKorea and SalesItaly.

Conflict Between Parent and Child Members

Authority always flows down the hierarchy from parent to child. Child members always have the access level of their parents, unless otherwise specified.

Example

Scenario 1:

User1 belongs to Team1 and ProfileA is assigned to Team1.
Two levels of data access profiles are defined for ProfileA.

The data access profiles for ProfileA are described in the following table:

Data Access Profile	Access	Dimension	Member
ProfileA	Write	Entity	Sales
ProfileA	Read Only	Entity	SalesAsia

In this case, the Write access of the Sales member flows down to its children. This flow is interrupted by assigning Read Only access to SalesAsia (a descendant of Sales), and SalesAsia’s access flows down to its descendants. As a result, User1 is able to send data to SalesItaly, but not to SalesKorea.

Example

Scenario 2:

User1 belongs to Team1 and ProfileA is assigned to Team1.
ProfileA has two levels of data access profiles.

The data access profiles for ProfileA are described in the following table:

Data Access Profile	Access	Dimension	Member
ProfileA	Read Only	Entity	Sales
ProfileA	Write	Entity	SalesAsia

In this case, the Read Only access of the Sales member flows down to its children. This flow is interrupted by assigning Write access to SalesAsia (a descendant of Sales), and SalesAsia’s access flows down to its descendants. As a result, User1 is able to send data to SalesKorea but not to SalesItaly.

Conflict When the Same Member Belongs to Different Hierarchies

When a member belongs to different hierarchies, and there is a conflict in member access, the most restrictive access is applied.

Example

Scenario: ProfileA and ProfileB are assigned to User1. The data access profiles are described in the following table:

Data Access Profile	Access	Dimension	Member
ProfileA	Read Only	Entity	WorldWide1
ProfileB	Write	Entity	WorldWide2

In this case, ProfileB determines User1’s access. As a result, User1 is able to send data to SalesKorea, even if ProfileA denies User1 Write access to SalesKorea (in WorldWide1 hierarchy).

Attribute Based Data Access Profiles

When you are creating a data access profile, you can assign different levels of access based on properties. The examples described below are based on the following hierarchy:

ID	Region	Country	Currency
Entity0	Europe	Germany	Euro
— Entity1	Europe	Germany	Euro
— — Entity101	Europe	UK	GBP
— — Entity102	Europe	France	Euro
— — Entity103	Europe	Germany	Euro
— Entity2	North America	USA	USD
— — Entity201	North America	USA	USD
— — Entity202	North America	Canada	CAD
— — Entity203	North America	Mexico	MXN

Example — One Data Access Profile

The data access profile DAP1 is defined as follows:

Rule Number	Members	Access	Comment	Result
1	Entity1	Read	Read access to Entity1 and all its descendants	Read access to Entity1, Entity101, Entity102, Entity103
2	Country = Germany and Currency = Euro	Write	Write access to members whose Country is Germany and Currency is Euro	Write access to Entity0, Entity1 and Entity103
3	Entity103	Deny	No access to Entity103	No access to Entity103

When there are conflicting rules in a data access profile, the priority is as follows (from highest to lowest):

Access defined exactly on the member (be it a base member or a parent member).
Access defined by attributes (will not be inherited).

Example

If the defined attributes are Currency=Euro: Read and Country=France: Write, then Entity102 is writable.
Access inherited from parent.
Access defined to “All members” (as if defined on a virtual parent on top of the hierarchy).

The result is shown in the table below:

ID	Access	Comment
Entity0	Write	Defined by rule number 2.
Entity1	Read	Read access defined by rule number 1; Write access defined by rule number 2. Rule number 1 is applied, because it applies directly to Entity1.
Entity101	Read	Defined by rule number 1.
Entity102	Read	Defined by rule number 1.
Entity103	Deny	Read access defined by rule number 1; Write access defined by rule number 2; Deny access defined by rule number 3. Rule number 3 is applied, because it applies directly to Entity103.
Entity2	Deny	If no rules exist, access is denied by default.
Entity201	Deny	If no rules exist, access is denied by default.
Entity202	Deny	If no rules exist, access is denied by default.
Entity203	Deny	If no rules exist, access is denied by default.

Example — Two Data Access Profiles

Data access profile DAP2 is defined as follows:

Rule Number	Members	Access	Comment	Result
1	All members	Read	Read access to all members	Read access to all members
2	Entity1	Deny	No access to Entity1 and its descendants	No access to Entity1, Entity101, Entity102 and Entity103
3	Currency = USD	Write	Write access to members whose currency is USD	Write access to Entity2 and Entity201

The result of this data access profile is shown in the table below:

ID	Access	Comment
Entity0	Read	Defined in rule number 1.
Entity1	Deny	Read access defined by rule number 1; Deny access defined in rule number 2. Rule number 2 is applied, because it applies directly to Entity1 and its descendants.
Entity101	Deny	Read access defined by rule number 1; Deny access defined in rule number 2. Rule number 2 is applied, because it applies directly to Entity1 and its descendants.
Entity102	Deny	Read access defined by rule number 1; Deny access defined in rule number 2. Rule number 2 is applied, because it applies directly to Entity1 and its descendants.
Entity103	Deny	Read access defined by rule number 1; Deny access defined in rule number 2. Rule number 2 is applied, because it applies directly to Entity1 and its descendants.
Entity2	Write	Read access defined by rule number 1; Write access defined in rule number 3. Rule number 3 is applied, because it applies directly to the properties of Entity 2.
Entity201	Write	Read access defined by rule number 1; Write access defined in rule number 3. Rule number 3 is applied, because it applies directly to the properties of Entity 201.
Entity202	Read	Defined by rule number 1.
Entity203	Read	Defined by rule number 1.

If several data access profiles are assigned to a user or a team, the combination of the least restrictive rules of all profiles is applied. Therefore, if both DAP1 and DAP2 are assigned to a user, that user will have the following permissions:

ID	Access granted by DAP1	Access granted by DAP2	Result
Entity0	Write	Read	Write access
Entity1	Read	Deny	Read access
Entity101	Read	Deny	Read access
Entity102	Read	Deny	Read access
Entity103	Deny	Deny	Access denied
Entity2	Deny	Write	Write access
Entity201	Deny	Write	Write access
Entity202	Deny	Read	Read access
Entity203	Deny	Read	Read access