Overview
Authentication Methods
Managed Identity
Definition
Managed Identities provide an automatically managed identity for applications to use when connecting to resources that support Microsoft Entra authentication. Without having to manage credentials, applications can use managed identities to obtain Microsoft Entra tokens.
When to use it
Ex:
- Authenticate from an Azure resource (link to services that support managed identities) to another Azure resource
- Authenticate from an Azure resource to Graph or 3rd party APIs
- Authenticate from a Gitlab CI job to Azure or a 3rt party APIs
- ...
How to get one ?
Directly from your subscription
To enable system-assigned managed identity on a Azure Resource that was originally provisioned without it:
- Your account needs to get assigned the Azure Resource Contributor role.
- Assign Managed Identity directly into the Azure Resource portal page, under Identity (on the right menu)
To enable user-assigned manage identity on an Azure Resource a VM :
- Your account needs the Azure Resource Contributor and Managed Identity Operator role.
- Assign Managed Identity directly into the Azure Resource portal page, under Identity (on the right menu)
The main difference between User and System manage identity is the system is linked to a Resource. If the Resource is deleted, the managed identity is also deleted. The user identity will remain on Azure even if the Resource linked is deleted.
App Registration (API)
Definition
Registering applications in Azure AD bridges your apps to Microsoft 365 seamlessly. When you register the application in Azure AD, a trusted relationship is established between Microsoft and the application, which gives you more granular control over your apps. App registrations allow you to configure API permissions, grant administrative permissions on Azure resources, and set permissions.
When to use it
Uses cases :
- Setup Authentication to a web application for all thales users
- Setup Authentication to a native application for all thales users
- Authenticate to another API (Graph or 3rd party)
How to get one ?
Limitations
Clients Secrets cannot exceed a lifetime of 365 days
Service Account
Definition
A TDP service account is normally used to authenticate a service directly under Azure AD. A service account consists of a username ending in "@svc.thalesdigital.io" and a complex password. This account can only authenticate a legacy service` or a service unable to use other authentification type to the TDF infrastructure.
This type of account should only be used as a last resort, when other authentication options do not apply to your request.
When to use it
Authenticate from Gitlab CI to Artifactory ?
How to get one ?
link to service account creation documentation
Limitations
Require a security exception to get one Require conditional access to authenticate from a trusted IP or an untrusted IP with a Security Exception etc..
What type of authentication should I request?
| Can using | Response | Descripion / Exemple |
|---|---|---|
| User or System Managed Identiry | Yes | This is the recommended authorization type on inside Azure AD for internal systems/services acceding internal resource. Example: Azure VM acceding a Storage Account. The authorization relies on VM system or user managed identity to get access through the stockage account IAM role |
| No | Go next | |
| App registration or WIF (*) | Yes | This option can grant access to azure resource from external (not on TDF Tenant) and internal (from TDF Tenant) to a Azure Resources only if the api permission allow them. Exemple: API giving access to a subscription to an CI/CD Pipeline for creating, managing and deleting Azure Resources. It is necessary to use the API "Client Secret" to enable access in "Delegated" or "Application" mode. |
| No | Go next | |
| Service Account | Yes | Use when none of these options is possible for your use case. Consists of a user account (Username / Password) that may or may not be subject to MFA and security policies. This type of account is not secure, since the secrets are known and may be used by several systems/services. |
| Exemple: User need to run a local service (eg: SQL Service) with a Azure Active Directory User. | ||
| No | No more option |
(*) Workload identity federation is a mechanism that enables trust between different security realms, such as between Azure and an external identity provider (e.g., an on-premises Active Directory or an identity provider like Azure AD B2C). This trust allows for seamless and secure access to resources and services across these realms. This method uses App Registrations (APIs), an option at the level of the types of secrets used to connect to them. WIF is based on OpenID and enables automatic management of authentication tokens. However, configuration between the two realms is required.
This type of authentication can be used by GitHub, GitLab (CI/CD pipeline integration), or any other OpenID service.