Working with combinedMultiValue

About the Identity Attributes Relationship Evaluation

Before delving into the combinedMultiValue parameter, it's important to understand how Authorization Policies rely on Identity Attributes as part of the Policy definition. Attributes such as department, location, job title, etc., make it possible to define which users are granted access to the organization’s resources and assets. Policies can be created using either single or multiple Attributes. Using the standard runtime decision calculation, all Attributes are aggregated and considered during the evaluation process.

To enable the organization to build stronger solutions, it is now possible to create Authorization requests that evaluate the relationship between the Identity Attributes as part of the decision process.

Using combinedMultiValue: true changes the focus of the same Policy to one in which the decision process considers the Identity Attributes as they relate to each other, rather than as an aggregated understanding of the Identity.

This is a relationship-based evaluation that can add a level of depth to the same Policies and is applied based on sending the combinedMultiValue: true When it sets to false, or this parameter is absent, the evaluation applies an aggregated understanding of the specified Attributes.

The Identity Attributes relationship evaluation can be implemented in both Access and Restrictive Policies. When the request contains the combinedMultiValue: true parameter, the relationship between the various Attributes is considered through the complete Policy evaluation process, including Dynamic Groups, Conditions, and Asset Rules.

The Identity Attributes relationship evaluation can be done from external repositories (main and aux). We recommend using a single source for performance optimization. The combinedMultiValue parameter can be used with the following API endpoints:
• Permit/Deny
• User Access Token
• Policy Resolution

When evaluating Identity Attributes relationship, Attributes sent from the following sources can be considered in the calculation.
• External repository
• Request body
• Sent as JWT

There are many use cases why an organization would want to apply Identity Attributes relationship evaluation in a Policy.
In the following use case example, the difference between these two methods is explained in detail.

GWA Global Bank Use Case Example

With steadily growing branches and customers, GWA Global Bank has decided that it needs to open additional headquarters. Currently, there are two headquarters, New York and London. The bank has chosen new locations in Berlin and Paris for the two new locations.
After months of preparation, they are now reviewing their Authorization policies to determine if any new Policies need to be created.

Among the issues raised was that all European branches, including the new headquarters, must be fully compliant with the European Union’s General Data Protection Regulation (GDPR) rules. To ensure that no personal data is compromised, they use relationship-based Access Decisions to ensure that only branch and bank managers within the EU have access to the data of EU citizens and companies.

In our use case scenario, we will focus on one user, JohnE, who commutes between London and Paris regularly, holding part-time positions in both places. In London, he works in the DEV department and has the role of Branch Manager. While in Paris, JohnE focuses his efforts in the Admin department and serves as an additional Bank Manager.
So, using the User Access Token endpoint, our question is, WHAT assets is the user (in this case), JohnE, allowed to access?

In a data table for GWA Global Bank’s Identities and Assets, the use case data can be expressed as follows:

Identity Data

According to the GDPR rules that GWA Global Bank needs to be compliant with, a new Policy has been added. Users can only access Assets that are in the same location.

Asset Data

GWA Global Bank has the following data servers. Each is associated with a department (DEPT) and location (LOCATION).

This table indicates that only Branch Managers who are located in the same country as the Asset are granted access to that Asset.
The new Asset Rule states that to be granted access to an Asset, the user’s DEPT and
LOCATION must match the entity.Location + entity.department.

Standard Access Decision Calculation

According to the aggregated results, the response grants User 1104 (JohnE) access to the following Assets:

These results were created based on an aggregation of JohnE’s Attributes, including being in the DEV and ADMIN departments in both London and Paris. While this may be valuable for setting some permissions or Policies, what the new Policy requires is consideration of the relationship between two Attributes (DEPT and LOCATION) as it relates to the Bank’s Assets.

Identity Attributes Relationship Evaluation

Identity Attributes relationship evaluation uses the same Attributes and Attribute sources as Standard Decision Access order in which the Attributes that appear in the array determine the relationship of the Attributes included in the JWT and Request body.

Using relationship-based evaluation Attributes results, User 1104 (JohnE) has access to the following Assets:

This is because JohnE works in the DEV department in London, and is therefore granted access to the DataServerEU (which is located in London). Since JohnE also works in the ADMIN department in Paris, he is granted access to the DataServerADM1 (which is located in Paris).