Using Managed identities for Azure with Service Fabric

A common challenge when building cloud applications is how to securely manage the credentials in your code for authenticating to various services without saving them locally on a developer workstation or in source control. Managed identities for Azure solve this problem for all your resources in Azure Active Directory (Azure AD) by providing them with automatically managed identities within Azure AD. You can use a service's identity to authenticate to any service that supports Azure AD authentication, including Key Vault, without any credentials stored in your code.

Managed identities for Azure resources are free with Azure AD for Azure subscriptions. There's no additional cost.


Managed identities for Azure is the new name for the service formerly known as Managed Service Identity (MSI).


Managed identities for Azure is based upon several key concepts:

  • Client ID - a unique identifier generated by Azure AD that is tied to an application and service principal during its initial provisioning (also see application ID.)

  • Principal ID - the object ID of the service principal object for your Managed Identity that is used to grant role-based access to an Azure resource.

  • Service Principal - an Azure Active Directory object, which represents the projection of an AAD application in a given tenant (also see service principal.)

There are two types of managed identities:

  • A System-assigned managed identity is enabled directly on an Azure service instance. The lifecycle of a system-assigned identity is unique to the Azure service instance that it's enabled on.
  • A user-assigned managed identity is created as a standalone Azure resource. The identity can be assigned to one or more Azure service instances and is managed separately from the lifecycles of those instances.

To further understand the difference between managed identity types, see How do managed identities for Azure resources work?.

Supported scenarios for Service Fabric applications

Managed identities for Service Fabric are only supported in Azure-deployed Service Fabric clusters, and only for applications deployed as Azure resources; an application that is not deployed as an Azure resource cannot be assigned an identity. Conceptually speaking, support for managed identities in an Azure Service Fabric cluster consists of two phases:

  1. Assign one or more managed identities to the application resource; an application may be assigned a single system-assigned identity, and/or up to 32 user-assigned identities, respectively.

  2. Within the application's definition, map one of the identities assigned to the application to any individual service comprising the application.

The system-assigned identity of an application is unique to that application; a user-assigned identity is a standalone resource, which may be assigned to multiple applications. Within an application, a single identity (whether system-assigned or user-assigned) can be assigned to multiple services of the application, but each individual service can only be assigned one identity. Lastly, a service must be assigned an identity explicitly to have access to this feature. In effect, the mapping of an application's identities to its constituent services allows for in-application isolation — a service may only use the identity mapped to it.

Currently, the following scenarios are supported for this feature:

  • Deploy a new application with one or more services and one or more assigned identities

  • Assign one or more managed identities to an existing (Azure-deployed) application in order to access Azure resources

The following scenarios are not supported or not recommended; note these actions may not be blocked, but can lead to outages in your applications:

  • Remove or change the identities assigned to an application; if you must make changes, submit separate deployments to first add a new identity assignment, and then to remove a previously assigned one. Removal of an identity from an existing application can have undesirable effects, including leaving your application in a state that is not upgradeable. It is safe to delete the application altogether if the removal of an identity is necessary; note this will delete the system-assigned identity (if so defined) associated with the application, and will remove any associations with the user-assigned identities assigned to the application.

  • Service Fabric support for managed identities is not integrated at this time into the AzureServiceTokenProvider.

Next steps