Sécuriser l’accès hybride avec l’intégration Microsoft Entra
Microsoft Entra ID prend en charge les protocoles d’authentification modernes qui permettent de sécuriser les applications. Toutefois, de nombreuses applications métier fonctionnent dans un réseau d’entreprise protégé, et certaines utilisent des méthodes d’authentification héritées. À mesure que les entreprises mettent en place des stratégies Confiance Zéro et prennent en charge des environnements hybrides et cloud, des solutions apparaissent pour connecter les applications à Microsoft Entra ID et fournir une authentification pour les applications héritées.
En savoir plus : Sécurité Confiance Zéro
Microsoft Entra ID prend en charge les protocoles modernes en mode natif :
- SAML (Security Assertion Markup Language)
- Fédération des services web (WS-Fed)
- OpenID Connect (OIDC)
Microsoft Entra proxy d’application ou Microsoft Entra proxy d’application prend en charge l’authentification Kerberos et basée sur l’en-tête. D’autres protocoles, tels que SSH (Secure Shell), NTLM (Microsoft Windows NT LAN Manager), LDAP (Lightweight Directory Access Protocol), et les cookies, ne sont pas pris en charge. Toutefois, les éditeurs de logiciels indépendants peuvent créer des solutions pour connecter ces applications avec Microsoft Entra ID.
Les ISV peuvent aider les clients à découvrir et à migrer des applications SaaS (software as a service) vers Microsoft Entra ID. Ils peuvent connecter des applications qui utilisent des méthodes d’authentification héritées avec Microsoft Entra ID. Les clients peuvent se regrouper dans Microsoft Entra ID pour simplifier la gestion de leurs applications et implémenter les principes de la Confiance Zéro.
Vue d’ensemble de la solution
La solution que vous créez peut inclure les composants suivants :
- Découverte d’applications - Souvent, les clients ne connaissent pas toutes les applications utilisées
- La découverte d’applications trouve les applications et facilite ainsi l’intégration des applications à Microsoft Entra ID
- Migration d’applications : créer un workflow pour intégrer les applications à Microsoft Entra ID sans utiliser le centre d’administration Microsoft Entra
- Intégrer les applications que les clients utilisent aujourd’hui
- Prise en charge de l’authentification héritée - Connecter les applications avec des méthodes d’authentification héritées et l’authentification unique (SSO)
- Accès conditionnel : permettre aux clients d’appliquer des stratégies Microsoft Entra aux applications de votre solution sans utiliser le centre d’administration Microsoft Entra
En savoir plus : Qu’est-ce que l’accès conditionnel ?
Consultez les sections suivantes pour des considérations et recommandations techniques.
Publication d’applications sur la Place de marché Azure
La Place de marché Azure est une source fiable d’applications pour les administrateurs informatiques. Les applications sont compatibles avec Microsoft Entra ID et prennent en charge l’authentification unique, automatisent l’approvisionnement d’utilisateurs et s’intègrent aux locataires externes avec l’inscription automatisée des applications.
Vous pouvez préintégrer votre application à Microsoft Entra ID pour prendre en charge l’authentification unique et le provisionnement automatisé. Consultez Envoyer une demande de publication de votre application dans la galerie d’applications Microsoft Entra.
Nous vous recommandons de devenir un éditeur vérifié pour que les clients sachent que vous êtes l’éditeur approuvé. Consultez Vérification de l’éditeur.
Activer l’authentification unique pour les administrateurs informatiques
Il existe plusieurs façons d’activer l’authentification unique pour les administrateurs informatiques dans votre solution. Consultez Planifier un déploiement de l’authentification unique - Options de l’authentification unique.
Microsoft Graph utilise OIDC/OAuth. Les clients utilisent OIDC pour se connecter à votre solution. Utilisez les émissions JSON Web Token (JWT) Microsoft Entra ID pour interagir avec Microsoft Graph. Consultez OpenID Connect sur la plateforme d’identités Microsoft.
Si votre solution utilise SAML pour l’authentification unique de l’administrateur informatique, le jeton SAML ne permet pas à votre solution d’interagir avec Microsoft Graph. Vous pouvez utiliser SAML pour l’authentification unique des administrateurs informatiques, mais votre solution doit prendre en charge l’intégration OIDC avec Microsoft Entra ID afin de pouvoir obtenir un jeton JWT Microsoft Entra ID pour interagir avec Microsoft Graph. Consultez Comment la plateforme d’identités Microsoft utilise le protocole SAML.
Vous pouvez utiliser l’une des approches SAML suivantes :
- Approche SAML recommandée : Créez une nouvelle inscription dans la Place de marché Azure, qui est une application OIDC. Les clients ajoutent les applications SAML et OIDC à leur locataire. Si votre application ne figure pas dans la galerie Microsoft Entra, vous pouvez commencer avec une application multilocataire hors galerie.
- Autre approche SAML : Les clients peuvent créer une inscription d’applications OIDC dans leur locataire Microsoft Entra et définir les URI, points de terminaison et autorisations
Utilisez le type d’octroi des informations d’identification client, qui demande que la solution autorise les clients à entrer un ID client et un secret. La solution vous demande également de stocker ces informations. Obtenez un jeton JWT à partir de Microsoft Entra ID, puis utilisez-le pour interagir avec Microsoft Graph. Consultez Obtenir un jeton. Nous vous recommandons de regarder la documentation des clients sur la création de l’inscription d’applications dans leur locataire Microsoft Entra. Incluez les points de terminaison, les URI et les autorisations.
Notes
Avant qu’une application ne soit utilisée pour l’authentification unique de l’administrateur informatique ou des utilisateurs, l’administrateur informatique du client doit consentir à l’application dans son locataire. Consultez Accorder le consentement de l’administrateur au niveau locataire à une application.
Flux d’authentification
Les flux d’authentification de la solution prennent en charge les scénarios suivants :
- L’administrateur informatique du client se connecte avec l’authentification unique (SSO) pour administrer votre solution
- L’administrateur informatique du client utilise votre solution pour intégrer des applications à Microsoft Entra ID avec Microsoft Graph
- Les utilisateurs se connectent aux applications héritées sécurisées par votre solution et Microsoft Entra ID
L’administrateur informatique de votre client se connecte à votre solution avec l’authentification unique
Votre solution peut utiliser SAML ou OIDC pour l’authentification unique quand l’administrateur informatique du client se connecte. Nous recommandons à l’administrateur informatique de se connecter à votre solution avec ses informations d’identification Microsoft Entra, ce qui permet d’utiliser les contrôles de sécurité actuels. Intégrez votre solution à Microsoft Entra pour l’authentification unique via SAML ou OIDC.
Le schéma suivant illustre le flux d’authentification utilisateur :
- L’administrateur informatique se connecte à votre solution avec ses informations d’identification Microsoft Entra
- La solution redirige l’administrateur informatique vers Microsoft Entra à l’aide d’une demande de connexion SAML ou OIDC
- Microsoft Entra authentifie l’administrateur informatique et le redirige vers votre solution avec un jeton SAML ou JWT à autoriser dans votre solution
Les administrateurs informatiques intègrent des applications avec Microsoft Entra ID
Les administrateurs informatiques intègrent les applications à Microsoft Entra en utilisant votre solution, qui se sert de Microsoft Graph pour créer des inscriptions d’applications et des stratégies d’accès conditionnel Microsoft Entra.
Le schéma suivant illustre le flux d’authentification utilisateur :
- L’administrateur informatique se connecte à votre solution avec ses informations d’identification Microsoft Entra
- La solution redirige l’administrateur informatique vers Microsoft Entra à l’aide d’une demande de connexion SAML ou OIDC
- Microsoft Entra authentifie l’administrateur informatique et le redirige vers votre solution avec un jeton SAML ou JWT pour l’autorisation
- Quand l’administrateur informatique intègre une application à Microsoft Entra , la solution appelle Microsoft Graph avec son jeton JWT pour inscrire des applications ou appliquer des stratégies d’accès conditionnel Microsoft Entra
Les utilisateurs se connectent aux applications
Quand les utilisateurs se connectent aux applications, ils utilisent OIDC ou SAML. Si les applications doivent interagir avec Microsoft Graph ou une API protégée par Microsoft Entra, nous vous recommandons de les configurer pour utiliser OICD. Cette configuration garantit que le jeton JWT est appliqué pour interagir avec Microsoft Graph. S’il n’est pas nécessaire que les applications interagissent avec Microsoft Graph ou avec des API protégées par Microsoft Entra, utilisez SAML.
Le schéma suivant montre le flux d’authentification utilisateur :
- L’utilisateur se connecte à une application
- La solution redirige l’utilisateur vers Microsoft Entra ID à l’aide d’une demande de connexion SAML ou OIDC
- Microsoft Entra authentifie l’utilisateur et le redirige vers votre solution avec un jeton SAML ou JWT pour l’autorisation
- La solution autorise la demande en utilisant le protocole d’application
API Microsoft Graph
Nous recommandons d’utiliser les API suivantes. Utilisez Microsoft Entra ID pour configurer des autorisations déléguées ou des autorisations d’application. Pour cette solution, utilisez les autorisations déléguées.
- API de modèles d’application - Dans la Place de marché Azure, utilisez cette API pour rechercher un modèle d’application correspondant
- Autorisations obligatoires : Application.Read.All
- API d’inscription d’applications - Créez des inscriptions d’applications OIDC ou SAML pour permettre aux utilisateurs de se connecter aux applications sécurisées avec votre solution
- Autorisations obligatoires : Application.Read.All, Application.ReadWrite.All
- API de principal de service - Après avoir inscrit l’application, mettez à jour l’objet du principal de service pour définir les propriétés SSO
- Autorisations obligatoires : Application.ReadWrite.All, Directory.AccessAsUser.All, AppRoleAssignment.ReadWrite.All (pour affectation)
- API d’accès conditionnel : Appliquer des stratégies d’accès conditionnel Microsoft Entra aux applications utilisateur
- Autorisations obligatoires : Policy.Read.All, Policy.ReadWrite.ConditionalAccess, Application.Read.All
En savoir plus : Utiliser l’API Microsoft Graph
Scénarios avec l’API Microsoft Graph
Utilisez les informations suivantes pour implémenter des inscriptions d’applications, connecter des applications héritées et activer des stratégies d’accès conditionnel. Découvrez comment automatiser le consentement de l’administrateur, obtenir le certificat de signature de jeton et affecter des utilisateurs et des groupes.
Utiliser Microsoft Graph API pour inscrire des applications avec l’ID de Microsoft Entra
Ajouter des applications dans la Place de marché Azure
Certaines applications que vos clients utilisent sont dans la Place de marché Azure. Vous pouvez créer une solution qui ajoute des applications au locataire externe. Utilisez l’exemple suivant avec l’API Microsoft Graph pour rechercher un modèle dans la Place de marché Azure.
Notes
Dans l’API de modèles d’application, le nom complet est sensible à la casse.
Authorization: Required with a valid Bearer token
Method: Get
https://graph.microsoft.com/v1.0/applicationTemplates?$filter=displayname eq "Salesforce.com"
Si vous trouvez une correspondance lors de l’appel d’API, capturez l’ID. Procédez à l’appel d’API suivant et fournissez un nom complet pour l’application dans le corps JSON :
Authorization: Required with a valid Bearer token
Method: POST
Content-type: application/json
https://graph.microsoft.com/v1.0/applicationTemplates/cd3ed3de-93ee-400b-8b19-b61ef44a0f29/instantiate
{
"displayname": "Salesforce.com"
}
Après avoir procédé à l’appel d’API, vous générez un objet de principal de service. Capturez l’ID de l’application et l’ID du principal de service à utiliser dans les prochains appels d’API.
Appliquez un correctif à l’objet du principal de service avec le protocole SAML et une URL de connexion :
Authorization: Required with a valid Bearer token
Method: PATCH
Content-type: servicePrincipal/json
https://graph.microsoft.com/v1.0/servicePrincipals/aaaaaaaa-bbbb-cccc-1111-222222222222
{
"preferredSingleSignOnMode":"saml",
"loginURL": "https://www.salesforce.com"
}
Corrigez l’objet de l’application avec les URI de redirection et les URI d’identificateur :
Authorization: Required with a valid Bearer token
Method: PATCH
Content-type: application/json
https://graph.microsoft.com/v1.0/applications/00001111-aaaa-2222-bbbb-3333cccc4444
{
"web": {
"redirectUris":["https://www.salesforce.com"]},
"identifierUris":["https://www.salesforce.com"]
}
Ajouter des applications, mais pas dans la Place de marché Azure
S’il n’existe aucune correspondance dans la Place de marché Azure ou pour intégrer une application personnalisée, inscrivez une application personnalisée dans Microsoft Entra ID avec l’ID de modèle : 8adf8e6e-67b2-4cf2-a259-e3dc5476c621. Ensuite, procédez à l’appel d’API suivant et fournissez un nom complet d’application dans le corps JSON :
Authorization: Required with a valid Bearer token
Method: POST
Content-type: application/json
https://graph.microsoft.com/v1.0/applicationTemplates/8adf8e6e-67b2-4cf2-a259-e3dc5476c621/instantiate
{
"displayname": "Custom SAML App"
}
Après avoir procédé à l’appel d’API, vous générez un objet de principal de service. Capturez l’ID de l’application et l’ID du principal de service à utiliser dans les prochains appels d’API.
Appliquez un correctif à l’objet du principal de service avec le protocole SAML et une URL de connexion :
Authorization: Required with a valid Bearer token
Method: PATCH
Content-type: servicePrincipal/json
https://graph.microsoft.com/v1.0/servicePrincipals/aaaaaaaa-bbbb-cccc-1111-222222222222
{
"preferredSingleSignOnMode":"saml",
"loginURL": "https://www.samlapp.com"
}
Corrigez l’objet de l’application avec les URI de redirection et les URI d’identificateur :
Authorization: Required with a valid Bearer token
Method: PATCH
Content-type: application/json
https://graph.microsoft.com/v1.0/applications/00001111-aaaa-2222-bbbb-3333cccc4444
{
"web": {
"redirectUris":["https://www.samlapp.com"]},
"identifierUris":["https://www.samlapp.com"]
}
Configurer l’authentification unique Microsoft Entra
Une fois que les applications SaaS sont inscrites dans Microsoft Entra ID, les applications doivent commencer à utiliser Microsoft Entra ID en tant que fournisseur d’identité (IdP) :
- Les applications prennent en charge SSO en un clic - Microsoft Entra ID active les applications. Dans le centre d’administration Microsoft Entra, le client procède à une authentification SSO en un clic avec les informations d’identification d’administration pour les applications SaaS prises en charge.
- Les applications ne prennent pas en charge SSO en un clic - Le client permet aux applications d’utiliser Microsoft Entra ID.
Connecter des applications à Microsoft Entra ID avec l’authentification héritée
Votre solution peut permettre au client d’utiliser l’authentification unique et les fonctionnalités Microsoft Entra, même les applications non prises en charge. Pour autoriser l’accès avec des protocoles hérités, votre application appelle Microsoft Entra ID pour authentifier l’utilisateur et appliquer des stratégies d’accès conditionnel Microsoft Entra ID. Activez cette intégration à partir de votre console. Créez une inscription d’application SAML ou OIDC entre votre solution et Microsoft Entra ID.
Créer une inscription d’application SAML
Utilisez l’ID du modèle d’application personnalisée suivant : 8adf8e6e-67b2-4cf2-a259-e3dc5476c621. Ensuite, procédez à l’appel d’API suivant et fournissez un nom complet dans le corps JSON :
Authorization: Required with a valid Bearer token
Method: POST
Content-type: application/json
https://graph.microsoft.com/v1.0/applicationTemplates/8adf8e6e-67b2-4cf2-a259-e3dc5476c621/instantiate
{
"displayname": "Custom SAML App"
}
Après avoir procédé à l’appel d’API, vous générez un objet de principal de service. Capturez l’ID de l’application et l’ID du principal de service à utiliser dans les prochains appels d’API.
Appliquez un correctif à l’objet du principal de service avec le protocole SAML et une URL de connexion :
Authorization: Required with a valid Bearer token
Method: PATCH
Content-type: servicePrincipal/json
https://graph.microsoft.com/v1.0/servicePrincipals/aaaaaaaa-bbbb-cccc-1111-222222222222
{
"preferredSingleSignOnMode":"saml",
"loginURL": "https://www.samlapp.com"
}
Corrigez l’objet de l’application avec les URI de redirection et les URI d’identificateur :
Authorization: Required with a valid Bearer token
Method: PATCH
Content-type: application/json
https://graph.microsoft.com/v1.0/applications/00001111-aaaa-2222-bbbb-3333cccc4444
{
"web": {
"redirectUris":["https://www.samlapp.com"]},
"identifierUris":["https://www.samlapp.com"]
}
Créer une inscription d’application OIDC
Utilisez l’ID de modèle suivant pour une application personnalisée : 8adf8e6e-67b2-4cf2-a259-e3dc5476c621. Procédez à l’appel d’API suivant et fournissez un nom complet dans le corps JSON :
Authorization: Required with a valid Bearer token
Method: POST
Content-type: application/json
https://graph.microsoft.com/v1.0/applicationTemplates/8adf8e6e-67b2-4cf2-a259-e3dc5476c621/instantiate
{
"displayname": "Custom OIDC App"
}
À partir de l’appel d’API, capturez l’ID de l’application et l’ID du principal de service à utiliser dans les prochains appels d’API.
Authorization: Required with a valid Bearer token
Method: PATCH
Content-type: application/json
https://graph.microsoft.com/v1.0/applications/{Application Object ID}
{
"web": {
"redirectUris":["https://www.samlapp.com"]},
"identifierUris":["[https://www.samlapp.com"],
"requiredResourceAccess": [
{
"resourceAppId": "00000003-0000-0000-c000-000000000000",
"resourceAccess": [
{
"id": "7427e0e9-2fba-42fe-b0c0-848c9e6a8182",
"type": "Scope"
},
{
"id": "e1fe6dd8-ba31-4d61-89e7-88639da4683d",
"type": "Scope"
},
{
"id": "37f7f235-527c-4136-accd-4a02d197296e",
"type": "Scope"
}]
}]
}
Notes
Les autorisations d’API dans le nœud resourceAccess accordent à l’application les autorisations openid, User.Read et offline_access, lesquelles permettent de se connecter. Consultez Vue d’ensemble des autorisations de Microsoft Graph.
Appliquer des stratégies d’accès conditionnel
Les clients et partenaires peuvent utiliser l’API Microsoft Graph pour créer ou appliquer des stratégies d’accès conditionnel. Pour les partenaires, les clients peuvent appliquer ces stratégies directement de votre solution sans utiliser le centre d’administration Microsoft Entra. Il existe deux options pour appliquer des stratégies d’accès conditionnel Microsoft Entra :
- Affecter l’application à une stratégie d’accès conditionnel
- Créer une stratégie d’accès conditionnel et affecter l’application à celle-ci
Utiliser une stratégie d’accès conditionnel
Pour obtenir la liste des stratégies d’accès conditionnel, exécutez la requête suivante. Obtenez l’ID d’objet de la stratégie à modifier.
Authorization: Required with a valid Bearer token
Method:GET
https://graph.microsoft.com/v1.0/identity/conditionalAccess/policies
Pour corriger la stratégie, incluez l’ID d’objet de l’application pour être dans l’étendue de includeApplications dans le corps JSON :
Authorization: Required with a valid Bearer token
Method: PATCH
https://graph.microsoft.com/v1.0/identity/conditionalAccess/policies/{policyid}
{
"displayName":"Existing Conditional Access Policy",
"state":"enabled",
"conditions":
{
"applications":
{
"includeApplications":[
"00000003-0000-0ff1-ce00-000000000000",
"{Application Object ID}"
]
},
"users": {
"includeUsers":[
"All"
]
}
},
"grantControls":
{
"operator":"OR",
"builtInControls":[
"mfa"
]
}
}
Créer une nouvelle stratégie d’accès conditionnel
Ajoutez l’ID d’objet de l’application pour qu’il soit dans l’étendue de includeApplications dans le corps JSON :
Authorization: Required with a valid Bearer token
Method: POST
https://graph.microsoft.com/v1.0/identity/conditionalAccess/policies/
{
"displayName":"New Conditional Access Policy",
"state":"enabled",
"conditions":
{
"applications": {
"includeApplications":[
"{Application Object ID}"
]
},
"users": {
"includeUsers":[
"All"
]
}
},
"grantControls": {
"operator":"OR",
"builtInControls":[
"mfa"
]
}
}
#Policy Template for Requiring Compliant Device
{
"displayName":"Enforce Compliant Device",
"state":"enabled",
"conditions": {
"applications": {
"includeApplications":[
"{Application Object ID}"
]
},
"users": {
"includeUsers":[
"All"
]
}
},
"grantControls": {
"operator":"OR",
"builtInControls":[
"compliantDevice",
"domainJoinedDevice"
]
}
}
#Policy Template for Block
{
"displayName":"Block",
"state":"enabled",
"conditions": {
"applications": {
"includeApplications":[
"{Application Object ID}"
]
},
"users": {
"includeUsers":[
"All"
]
}
},
"grantControls": {
"operator":"OR",
"builtInControls":[
"block"
]
}
}
Automatiser le consentement administrateur
Si le client ajoute des applications de votre solution à Microsoft Entra ID, vous pouvez automatiser le consentement de l’administrateur avec Microsoft Graph. Vous avez besoin de l’ID d’objet du principal de service de l’application que vous avez créé dans les appels d’API et de l’ID d’objet du principal de service de Microsoft Graph du locataire externe.
Récupérez l’ID d’objet du principal de service de Microsoft Graph en procédant à l’appel d’API suivant :
Authorization: Required with a valid Bearer token
Method:GET
https://graph.microsoft.com/v1.0/serviceprincipals/?$filter=appid eq '00000003-0000-0000-c000-000000000000'&$select=id,appDisplayName
Pour automatiser le consentement de l’administrateur, procédez à l’appel d’API suivant :
Authorization: Required with a valid Bearer token
Method: POST
Content-type: application/json
https://graph.microsoft.com/v1.0/oauth2PermissionGrants
{
"clientId":"{Service Principal Object ID of Application}",
"consentType":"AllPrincipals",
"principalId":null,
"resourceId":"{Service Principal Object ID Of Microsoft Graph}",
"scope":"openid user.read offline_access}"
}
Obtenir le certificat de signature de jetons
Pour obtenir la partie publique du certificat de signature de jetons, utilisez GET à partir du point de terminaison de métadonnées Microsoft Entra de l’application :
Method:GET
https://login.microsoftonline.com/{Tenant_ID}/federationmetadata/2007-06/federationmetadata.xml?appid={Application_ID}
Affecter des utilisateurs et des groupes
Après avoir publié l’application sur Microsoft Entra ID, vous pouvez attribuer l’application aux utilisateurs et aux groupes pour vous assurer qu’elle apparaît dans le portail Mes applications. Cette attribution est sur l’objet du principal de service généré quand vous avez créé l’application. Consultez Vue d’ensemble du portail Mes applications.
Obtenez les instances AppRole que l’application peut lui avoir associées. Il est fréquent qu’une application SaaS soit associée à plusieurs instances AppRole. Généralement, pour les applications personnalisées, il y a une instance AppRole par défaut. Récupérez l’ID de l’instance AppRole que vous souhaitez attribuer :
Authorization: Required with a valid Bearer token
Method:GET
https://graph.microsoft.com/v1.0/servicePrincipals/aaaaaaaa-bbbb-cccc-1111-222222222222
Dans Microsoft Entra ID, obtenez l’ID d’objet de l’utilisateur ou du groupe que vous souhaitez attribuer à l’application. Prenez l’ID de rôle de l’application dans l’appel d’API précédent et envoyez-le avec le corps du correctif sur le principal de service :
Authorization: Required with a valid Bearer token
Method: PATCH
Content-type: servicePrincipal/json
https://graph.microsoft.com/v1.0/servicePrincipals/aaaaaaaa-bbbb-cccc-1111-222222222222
{
"principalId":"{Principal Object ID of User -or- Group}",
"resourceId":"{Service Principal Object ID}",
"appRoleId":"{App Role ID}"
}
Partenariats
Pour contribuer à la protection des applications existantes tout en utilisant les contrôleurs de réseau et de livraison, Microsoft a des partenariats avec les fournisseurs de contrôleurs de livraison d’applications (ADC) suivants.
- Akamai Enterprise Application Access
- Citrix ADC
- F5 BIG-IP Access Policy Manager
- Kemp LoadMaster
- Pulse Secure Virtual Traffic Manager
Les fournisseurs de solutions VPN suivants se connectent à Microsoft Entra ID pour proposer des méthodes d’authentification et d’autorisation modernes, telles que l’authentification unique et l’authentification multifacteur (MFA).
- Cisco Secure Firewall – Secure Client
- Fortinet FortiGate
- F5 BIG-IP Access Policy Manager
- Palo Alto Networks GlobalProtect
- Pulse Connect Secure
Les fournisseurs de solutions de périmètre défini par logiciel (SDP) suivants se connectent à Microsoft Entra ID pour proposer des méthodes d’authentification et d’autorisation comme les authentifications SSO et MFA.
- Répartiteur d’accès DatawizaDatawiza Access Broker
- Perimeter 81
- Plateforme d’authentification Silverfort
- Maverics Identity Orchestrator de Strata
- Zscaler Private Access