Best practices for securing the custom extension extensibility to Azure Logic Apps

This article describes the best practices for securing the Microsoft Entra ID Governance custom extension extensibility to Azure Logic Apps. The guidance is specific to entitlement management, Lifecycle Workflows, and complementary to the general security guidance published for Azure Logic Apps.

The best practices described in this article include:

  • Securing administrative access to the subscription
  • Disabling shared access signature (SAS)
  • Using managed identities for authentication
  • Authorizing with least privileged permissions
  • Ensuring Proof-of-Possession (PoP) usage

Secure administrative access to the subscription

The administrative access to the Azure Subscriptions hosting your Logic Apps should be secured. We recommend following the Cloud Adoption Framework, and if possible, placing the Logic Apps in the Identity Subscription. For more information, see:What is an Azure landing zone?

Disable shared access signature (SAS)

Inbound calls to Logic Apps can use only one authorization scheme, Microsoft Entra ID access tokens, or shared access signature (SAS). Using one scheme, however, doesn't disable the other scheme. Calls from Microsoft Entra ID Governance to Logic Apps are authorized via the Microsoft Entra ID access token authorization scheme.

We highly recommend you disable the shared access signature (SAS) authorization scheme on your Logic Apps as it is not required by Microsoft Entra ID Governance. Disabling the shared access signature (SAS) authorization scheme eliminates the risk of the signature being exposed, or subject, to unauthorized access.

All Logic Apps created via the Microsoft Entra ID Governance custom extensions user interfaces after April 29, 2024 have the shared access signature (SAS) authorization scheme disabled by default.

If you created a Logic App via the Microsoft Entra ID Governance custom extensions user interfaces on, or before, April 29, 2024, follow the guidance to disable the shared access signature (SAS) authorization scheme located here: Disable shared access signature (SAS) authentication (Consumption only).

Use managed identities for authentication

The management of secrets, credentials, certificates, and keys used to secure communication between services is a common challenge. Managed identities eliminate the need to manage these credentials. If you're using the custom extension "launch and wait" pattern(entitlement management reference; Lifecycle Workflow reference), we highly recommend you enable the Azure Logic Apps managed identity to authenticate the resume calls(taskProcessingResult: resume; accessPackageAssignmentRequest: resume) to Microsoft Entra ID Governance. If your scenario requires the Logic App to call other Microsoft Graph endpoints, or even other Microsoft Entra integrated services, you can also use the managed identity to authenticate calls against these services.

Entitlement management: You have to enable the managed identity yourself. For information on this process, see: Enable system-assigned identity in the Azure portal and then authorize it.

Lifecycle Workflows: The managed identity is automatically enabled, and authorized, for "launch and wait" custom extensions. If your Logic App needs to call other services, you can use and authorize the same managed identity. For ‘launch and continue’ custom extensions, you have to enable the managed identity yourself.

For steps on how to use the managed identity with a Logic Apps action, see: Authenticate access with managed identity..

Authorize with least privileged permissions

The resume calls from Logic Apps to Microsoft Entra ID Governance can be authorized directly within Lifecycle Workflows and entitlement management. When authorized directly, you're NOT required to assign the managed identity application permissions such as LifecycleWorkflows.ReadWrite.All or Entitlement Management.ReadWrite.All.

Guidance for assigning the least privileged permissions:

Assign least privileged permissions with entitlement management

Assign the managed identity the ‘access package assignment manager’ role for a given catalog to authorize the resume call. For more general guidance on how to assign roles for a catalog, see: As a catalog owner, delegate to an access package manager.

Assign least privileged permissions with Lifecycle Workflows

The managed identity can be directly authorized for the resume call within the custom extension settings. Lifecycle Workflows automatically set this up for you during the custom extension creation process. For more information, see: Response authorization.

Assign least privileged permissions with other services and scenarios

If you need to authorize the Logic App to call other services integrated with Microsoft Entra ID, such as other Microsoft Graph APIs, consider that the managed identity can also get privileges through role assignments in various role-based access control systems, which often allow you to follow the principle of least privilege. Non-exhaustive list of examples include:

  • If your entitlement management custom extension needs to query additional information from entitlement management you can assign the Logic App one of the roles in entitlement management, such as catalog reader, for a given catalog. This allows you to reduce the permissions and scope compared to the tenant-wide EntitlementManagement.Read.All and/or EntitlementManagement.ReadWrite.All application permissions.
  • If you want to use a Lifecycle Workflow custom extension to generate a temporary access pass opposed to the built-in task, you can assign the managed identity the authentication administrators Microsoft Entra built-in role scoped to an administrative unit, opposed to assigning it the UserAuthenticationMethod.ReadWrite.All application permissions, which would drastically increase the blast radius if the Logic App would get compromised.

For more information regarding Microsoft Graph authorization, see: Get access without a user.

Ensure Proof-of-Possession (PoP) usage

Logic Apps supports either the bearer, or proof-of-possession, type access tokens for the Microsoft Entra ID access token authorization scheme. At the beginning of the Microsoft Entra ID Governance custom extensions public preview, bearer, opposed to Proof-of-Possession (PoP), access tokens were used to authorize the calls from Microsoft Entra ID Governance to Logic Apps.

Since moving to general availability, all custom extensions created via Microsoft Entra ID Governance user interfaces, and Microsoft Graph v1.0 endpoints, are by default using the proof-of-possession access tokens authorization scheme.

If your environment still contains custom extensions relying on bearer type access tokens, we recommend switching to proof-of-possession type access tokens.

To determine the authorization scheme currently used by your custom extensions, refer to the token security column shown in the Microsoft Entra admin center:

Screenshot of task list with token section visible.

Access token type Microsoft Entra admin center token security column
Bearer Regular
Proof-of-Possession (PoP) Proof-of-possession

Lifecycle Workflow's custom extensions can't be migrated from bearer to proof-of-possession type access tokens. You have to create new custom extensions and configure them in the corresponding workflows.

For a subset of entitlement management custom extensions, you can use the ‘Update to new extension type’ option available via the entitlement management user interface. To update to a new extension type, you'd do the following steps:

  1. Sign in to the Microsoft Entra admin center as at least an Identity Governance Administrator.

  2. Browse to Identity governance > Entitlement management > Catalogs.

  3. Select the catalog with the custom extension you want to update.

  4. On the catalog overview page, select Custom extensions.

  5. On the custom extensions page, find a custom extension whose token security says Regular and select the three lines next to it. Screenshot of the update to new type of token security.

  6. Select Update to new extension type.

Note

If the update function fails, a new custom extension must be created and configured in the corresponding access package assignment policies.