Azure AD (Microsoft Entra ID)

You can use your organization's Azure AD as a Data Source for the Authorization Platform. In this article, you can find a detailed User Property table and explanation on how to set up your Azure AD as a Policy Information Point (PIP) Data Source in PlainID.
Note: Currently, the Azure AD Connector can be used with Identity Templates only.

To create a Data Source based on Azure AD:

1. In either the Environment Settings or Tenant Settings screens, select the PIP Settings tab.
2. From the Policy Authorization Agent drop-down list, select the PAA in which you wish to create the new Data Source.
3. Click New Data Source.
4. In the Name field, enter the name of the new Data Source.
   Note: The Data Source name must be unique.
5. Under Connection Adapter, select Azure Active Directory.

• Under the Connection Settings, you will find Policy Authorization Agent settings (grey box) for each agent in your PAA group (see Data Sources):

  • Choose your Policy Authorization Agent from the drop-down.

  • In the End Point field add this value - https://graph.microsoft.com/v1.0 (This is the Microsoft Azure Active Directory endpoint).

7. Click Test Connection. The Test Connection button validates network communication from the PAA out to the Azure AD.

• Note: At this stage, PlainID does not perform an authentication flow and thus does not validate your AAD credentials.

8. Under the Models section, in the Name field, enter a virtual schema name.
   Note: The Model name must be unique.

9. Under DDL field, write a valid DDL to fetch the Azure Attributes. This is a default usage for AAD to fetch users and groups. You can copy the snippet in the Valid DDLs section of this article.

10. Click Create to save your configuration settings and create the Data Source object in the Platform.

Valid DDLs

AAD Default Usage

CREATE FOREIGN TABLE Users (id string NOT NULL, displayName string UNIQUE, userPrincipalName string NOT NULL, CONSTRAINT PK_USERS PRIMARY KEY(id)) OPTIONS (UPDATABLE TRUE, nameinsource 'Users', "teiid_odata:EntityType" 'users', "teiid_odata:Type" 'ENTITY_COLLECTION');

CREATE FOREIGN TABLE UserGroups (displayName string UNIQUE, userID string OPTIONS (UPDATABLE FALSE, "teiid_odata:PSEUDO" 'true'), id string, FOREIGN KEY(userID) REFERENCES Users (id), CONSTRAINT PK_USERRS_GROUPS PRIMARY KEY(userID, id)) OPTIONS (NAMEINSOURCE 'memberOf', UPDATABLE TRUE, "teiid_odata:NameInSchema" 'memberOf', "teiid_odata:Type" 'NAVIGATION_COLLECTION');

Note: The example above is the recommended DDL. For more advanced settings and options, you can contact our Professional Services team for assistance with specific requirements and use cases. It's important to note that using the "Generate DDL" option for the AAD adapter should be avoided.

AAD Custom Attributes

In the Model DDL, users have the ability to incorporate custom attributes into AAD's URI SELECT clause. When managing the Inner Attribute of a Complex Custom Attribute, an attribute option should be added to guide the translator to fetch an inner attribute. This option should be added to the attribute plainid:inner-attribute-jsonpathwith a JSONPath to the inner attribute similar to'$.extensionAttribute1'.

Users can employ plainid:parser as a parser type for the inner attribute JSONPATH. This parser type offers two options:

• directAttribute (Default type for non-nested structures.)
• jsonpath (Useful for Inner Attributes requiring JSONPath parsing and for complex Custom Attributes.)

Users can also make use of a native Entra Attribute using the following syntax:

onPremisesExtensionAttributes string options ("plainid:inner-attribute-jsonpath" '$.extensionAttribute1', "plainid:parser" 'jsonpath')

Full DDL Example:

CREATE FOREIGN TABLE Users (id string NOT NULL, onPremisesExtensionAttributes string options ("plainid:inner-attribute-jsonpath" '$.extensionAttribute1', "plainid:parser" 'jsonpath'), displayName string UNIQUE, userPrincipalName string NOT NULL, CONSTRAINT PK_USERS PRIMARY KEY(id)) OPTIONS (UPDATABLE TRUE, nameinsource 'Users', "teiid_odata:EntityType" 'users', "teiid_odata:Type" 'ENTITY_COLLECTION');

Fetching User Properties

To facilitate fetching and filtering User Groups, PlainID provides various properties that can be utilized. Each property serves a specific purpose. You can find more information about each property in the sections below the table.

Fetching Nested Groups

By default, the DDL fetches users and their corresponding group by direct membership. However, if you need to fetch nested groups (transitive groups), you can enable the enableNestedMemberOf property. This property allows groups to be fetched from the Azure Active Directory using the transitiveMemberOf endpoint. It's important to note that fetching nested groups can impact performance, and it is recommended to use this property when processing a single user. Please be aware that the option to retrieve more than a single user is not supported when enableNestedMemberOf is set to true and the enableGroupFirstMemberOf is set to false.

Filtering Groups

Filtering by Groups improves performance by reducing the number of AAD Groups queried and only fetching User-Group data that is relevant. Users have the following options for filtering:

Object Attributes
Users can filter based on Group Attributes, which can be done in two ways:

1. Filter on View: Users can apply a filter as a WHERE clause on the relevant groups' View definition. This WHERE clause can be dynamic-based on the query sender in the PIP.
2. Users can append an MS Graph API Groups filter by utilizing the graphApiFiltertoAppend property. This will use any native filter with a valid Graph API syntax and use it, in addition to other filtering, when making the Groups request to AAD.

Filtering by Including and Excluding Group Names
Users can specify a list of Group Names that should be included or excluded in the fetched subset of groups using the includeGroupsListor excludeGroupsList properties. This filters the subset of fetched Groups further before processing them and fetching their User Members.

Page Size

Administrators now have the ability to extend the page size to 999 objects using the defaultPageSize translator property. This allows for a more comprehensive data retrieval when handling larger datasets. The feature utilizes the GraphAPI $top option to retrieve a larger number of results in each paginated response.

Using Expand MemberOf

Administrators can utilize the parameter, useExpandMemberOf, which allows them to choose between two methods for fetching group membership data. This parameter can be set to either true or `false:

• When set to true, PlainID utilizes the GraphAPI expand feature for efficient data fetching, especially when many users are members of fewer than 20 groups. However, it's important to note that this choice is due to a known limitation in the GraphAPI.

• When set to false, PlainID does not utilize the expand feature. This setting is effective when most users are members of more than 20 groups.

Fetching Users Using Parallel Threads

To improve the performance of data fetching from Azure Active Directory (AAD), PlainID has implemented a threading capability. Users can take advantage of this feature by setting the maxWorkers translator property. The maxWorkers property specifies the maximum number of workers or concurrent threads that can be used for fetching group-related data. The default value is set by the translator property. However, it is recommended to fine-tune this value based on your specific scenario to achieve the best performance. Consider factors such as your specific data, network, and other considerations when adjusting the maxWorkers value.

Azure Active Directory Permissions

To be able to connect to your Azure AD and use it as a PIP Data Source, verify that you have client credentials set up and this client has sufficient permissions in Azure.
In your Azure AD console, under API Permissions, make sure you have the following permissions under Microsoft Graph APIs:

• GroupMember.Read.All
• User.Read.All

Use the screenshot below as a reference and consult your Azure AD Administrator.

For further assistance, contact PlainID's Support Team.