Microsoft Entra ID (Azure AD)

You can use Microsoft Entra ID (formerly Azure Active Directory) as a Policy Information Point (PIP) Data Source in the PlainID Authorization Platform. This setup allows you to pull user and group data directly from Entra ID into the Platform’s policy evaluation flow.

Note: The Microsoft Entra ID connector is currently supported only with Identity Templates.

Refer to the User Property Table for a detailed breakdown of available attributes and capabilities.

Creating a Microsoft Entra ID Data Source

1. In either the Environment Settings or Tenant Settings screen, open the PIP Settings tab.

2. From the Policy Authorization Agent dropdown, select the PAA where you'd like to configure the new Data Source.

3. Click New Data Source.

4. Provide a unique name for your Data Source.

5. Under Connection Adapter, select Azure Active Directory.

6. In the Connection Settings section:

   • Select your Policy Authorization Agent from the dropdown.
   • Enter the Microsoft Graph API endpoint:
     https://graph.microsoft.com/v1.0
   • Follow the OAuth configuration instructions:
     

     • If using OAuth Authentication with your Data Source, modify the following inputs in the Policy Authorization Agent section(s):

       • Under the Security Type field, choose None.

       • In the Translator Properties section, add the following properties with these key-value pairs:

         • Key = authConf, Value = "<path of the auth-config.xml file as described in OAuth2 Authentication Support.>"
         • Key = securityDomain, Value = "<name of the application-policy in your service's XML file.>"

     Note: Ensure that all PAAs in each group share the same XML file.

     Click here for more information about setting up OAuth for your Data Sources.

7. Click Test Connection to validate network communication between the PAA and Microsoft Entra ID.

   Note: This test only checks connectivity. It does not validate Entra ID credentials at this stage.

8. Under the Models section, enter a unique name for the virtual schema.

9. In the DDL field, define a valid DDL to fetch Microsoft Entra attributes. See Valid DDLs for examples and syntax.

10. Click Create to finalize the Data Source configuration.

Valid DDLs

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: This is the recommended schema for most use cases. Avoid using the "Generate DDL" option for the Entra ID connector.

Custom Attributes

You can fetch custom or nested attributes from Entra ID using JSONPath. Use the plainid:inner-attribute-jsonpath option, with plainid:parser to define how the inner attribute should be handled.

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

Full 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'
);

Translator Properties

You can optionally configure translator properties for more control over how data is fetched. These properties allow customization such as filtering, paging, multithreading, and fetching nested group relationships.

For advanced filtering, performance tuning, and other use cases, refer to the sections below.

Fetching User Properties

PlainID supports several translator properties to control how user and group data is fetched from Entra ID:

Fetching Nested Groups

Set enableNestedMemberOf=true to use the transitiveMemberOf Graph API endpoint and fetch hierarchical group memberships.

⚠️ This option only works for single-user queries when enableGroupFirstMemberOf=false.

Filtering Groups

You can filter group data in several ways:

1. Object Attribute Filtering

• Add a WHERE clause in the View definition.
• Use graphApiFilterToAppend for native Graph API filters, e.g.:
  startswith(displayName,'HR') or groupTypes/any(c:c eq 'Unified')

⚠️ Not all SQL WHERE clauses translate successfully to Graph API.

2. Include/Exclude Lists

• Use includeGroupsList or excludeGroupsList to define group subsets.
• Lists must be comma-separated with no spaces.

Page Size

Adjust the defaultPageSize property to control how many results are fetched per Graph API request (up to 999). This can significantly impact performance with large datasets.

Using Expand MemberOf

Set useExpandMemberOf=true to use Graph API's $expand=memberOf, which is efficient if most users belong to fewer than 20 groups.

⚠️ If enableGroupFirstMemberOf=true, you must set useExpandMemberOf=false.

Fetching Users Using Parallel Threads

Use the maxWorkers property to enable multithreading for group data fetching. This improves performance on large Entra ID environments. Adjust based on your environment and performance goals.

Redis-Based Request Distributed Caching

Required Microsoft Entra Permissions

Ensure your app registration in Microsoft Entra ID has the following Microsoft Graph API permissions:

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

You can find these settings under API Permissions in the Azure portal:

Need help? Contact PlainID Support.