SUR CETTE PAGE
Q : Quels sont les éléments de base de l’implémentation SSO de Mist que je devrais connaître ?
Q : Quelles sont les IdP prises en charge par Mist pour l’accès SSO ?
Q : Dois-je provisionner manuellement mes utilisateurs SSO dans Mist ?
Q : Quel est le processus de première connexion pour mes utilisateurs SSO ?
Q : Comment puis-je savoir quels utilisateurs SSO ont accédé à mon organisation ?
Q : J’ai besoin de plusieurs SSO dans mon organisation. Est-ce que Mist prend en charge cela ?
Q : J’ai plusieurs organisations, puis-je utiliser l’SSO avec plusieurs organisations ?
Q : Que se passe-t-il lorsque je supprime un SSO dans Mist ?
Q : Comment les jetons API fonctionnent-ils avec les utilisateurs SSO ?
Questions fréquentes sur l’authentification unique en SSO
Obtenez des réponses aux questions les plus fréquemment posées sur l'implémentation, les exigences, le provisionnement des SSO de Mist, et bien plus encore.
Q : Quels sont les éléments de base de l’implémentation SSO de Mist que je devrais connaître ?
R : Mist prend en charge le SSO basé sur SAML2.0 dans plusieurs parties de notre produit, avec des implémentations identiques. Bien que ce document ait été rédigé pour les SSO d’administration, nous prenons également en charge SSO pour l’accès invité, ainsi que le provisionnement automatique des PPSK lorsque les implémentations sont identiques, à l’exception des attributs obligatoires. Ce document peut donc être appliqué à toutes les SSO de Mist.
Un compte d’utilisateur dans Mist peut être l’un des trois types de comptes, en fonction de la façon dont il s’authentifie auprès de Mist ; en tant que compte local vers Mist, et compte SSO, ou compte OAUTH2. Un compte ne peut être que l’un de ces types. Ainsi, un compte SSO s’authentifie toujours auprès de Mist via l’IdP (sauf si l’utilisateur change de type de compte).
Assurez-vous de signer l’assertion et la réponse IdP et de renvoyer les attributs corrects dans l’assertion avec une majuscule correcte des noms d’attribut.
Q : Quelles sont les IdP prises en charge par Mist pour l’accès SSO ?
R : Mist prend en charge tout IdP prenant en charge SAML2.0.
Q : Est-ce que Mist prend en charge les SSO initiés par les fournisseurs de services et les fournisseurs de matériel ?
R : Oui, Mist prend en charge l’SSO initié par les fournisseurs de services et les fournisseurs de matériel IDP. À ceci près que la toute première connexion d’un utilisateur SSO à Mist doit provenir d’un IdP. Remarque : pour les connexions initiées par le fournisseur de services, l’ID d’entité saisi dans l’IdP doit être le même que l’URL ACS.
Q : Quels attributs dois-je envoyer dans mon assertion ?
R : Voici les attributs attendus par Mist dans l’assertion SAML :
Notez que les majuscules sont importantes.
- NameID
- Rôle
- Prénom
- Nom
NameID est requis. Le rôle est obligatoire, sauf si vous configurezdefault_rolevia une API. Le prénom et le nom sont recommandés, sinon vous verrez ? ? comme nom et prénom de l’utilisateur.
Q : Quels formats NameID prenez-vous en charge ?
R : NameID est utilisé comme identifiant unique pour l’utilisateur. Nous prenons en charge les e-mails et non spécifiés. La plupart des gens utilisent le courrier électronique, mais vous pouvez vraiment envoyer n’importe quoi tant que vous ne spécifiez pas de configuration dans la configuration Mist SSO. Si vous utilisez non spécifié, vous pouvez nous envoyer à peu près n’importe quoi, tant que c’est unique et cohérent. Vous verrez que nous générons un ID unique pour l’utilisateur dans Mist avec non spécifié.
Q : À quoi sert un rôle ?
R : Le rôle est utilisé pour dériver l’autorisation que l’utilisateur doit recevoir. Le rôle renvoyé dans l’assertion correspondrait à un rôle dans la configuration du rôle Mist SSO sur la page des paramètres de l’organisation. Veuillez noter que l’autorisation utilisateur est générée dynamiquement par connexion SSO.
Q : Puis-je renvoyer plusieurs rôles à un utilisateur ?
R : Oui, si plusieurs rôles sont renvoyés et mis en correspondance, nous prendrons le surensemble des autorisations. Veuillez noter que par défaut, tous les rôles doivent correspondre, sinon l’utilisateur se verra refuser l’accès. Pour permettre une correspondance partielle des rôles, il existe une option API ignore_unmatched_roles. Alternativement, il existe également une option API default_role, lorsqu’aucun rôle ne correspond.
Nous acceptons plusieurs rôles dans une variété de formats dans l’assertion. Plusieurs rôles peuvent être envoyés sous forme de paires séparées par virgule, de plusieurs paires AttributeValue ou avec une analyse CN. En voici quelques exemples :
Attributs de « rôle » séparés par des virgules
<Attribute Name="Role">
<AttributeValue>"Employee,Mist,Developer"</AttributeValue>
</Attribute>
# liste analysée des rôles
['Employee', 'Mist', 'Developer']
Plusieurs paires de valeurs d’attribut « Rôle »
<Attribute Name="Role">
<AttributeValue>"Employee"</AttributeValue>
<AttributeValue>"Mist"</AttributeValue>
<AttributeValue>"Developer"</AttributeValue>
</Attribute>
# liste analysée des rôles
['Employee', 'Mist', 'Developer']
Combinaison de paires AV séparées par des virgules et multiples
<Attribute Name="Role">
<AttributeValue>"Employee,Mist"</AttributeValue>
<AttributeValue>"Developer"</AttributeValue>
</Attribute>
# liste analysée des rôles
['Employee,Mist', 'Developer']
Exemple d’extraction de CN – « role_attr_extraction » : « CN »,
<saml2:Attribute ="Role">
<saml2:AttributeValue>CN=Employee,OU=groups,OU=ou1,OU=ou2</saml2:AttributeValue>
<saml2:AttributeValue>CN=Mist,OU=groups,OU=ou1,OU=ou2</saml2:AttributeValue>
<saml2:AttributeValue>CN=Developer,OU=ou1,OU=ou2</saml2:AttributeValue>
</saml2:Attribute>
# liste analysée des rôles
['Employee’, ‘Mist', 'Developer']
Q : Comment puis-je résoudre les échecs de SSO ?
R : Vous pouvez afficher les échecs en envoyant cet appel d’API : {api_endpoint}/api/v1/orgs/ :{org_id}/ssos/ :{sso_id}/failures
Vous verrez la raison de l'échec ainsi que l'affirmation reçue.
Pour émettre l'appel d'API, vous devez remplacer les termes en italique entre crochets par les valeurs réelles.
-
{api_endpoint}
Si vous n'êtes pas sûr de l'URL du point de terminaison de l'API de votre organisation, vous pouvez la dériver de l'URL de votre portail Juniper Mist. L’URL du portail commence par gérer. L’URL de point de terminaison d’API correspondante remplace manage par api. Notez les caractères gras dans les exemples suivants.
URL du portail
manage.ac2.mist.com/admin/ ?org_id=xxxxxxx-xxxx-xxx
URL de point de terminaison API correspondante
api.ac2.mist.com/admin/ ?org_id=xxxxxxx-xxxx-xxx
-
{org_id}
Vous pouvez également trouver votre ID d’organisation dans l’URL du portail Juniper Mist. L’ID apparaît après les caractères org_id=. Notez les caractères en gras dans l’exemple suivant.
ID d’organisation dans l’URL du portail
manage.ac2.mist.com/admin/?org_id=12345678-1a2b-3456cdef-xyz123
- {sso_id}
Pour trouver votre ID SSO, lancez cet appel API : {api_endpoint}/api/v1/orgs/ :{org_id}/ssos
Regardez dans le champ ID pour trouver votre ID SSO.
Q : Dois-je provisionner manuellement mes utilisateurs SSO dans Mist ?
R : Non, vous ne le faites pas. L’accès aux utilisateurs SSO est accordé à la demande par votre fournisseur d’identité. C’est-à-dire que les utilisateurs de SSO sont authentifiés par l’IdP, pas mais par Mist. Le niveau d’accès au tableau de bord Mist est contrôlé par l’attribut role renvoyé dans l’assertion correspondant à un rôle défini dans Mist.
Q : Quel est le processus de première connexion pour mes utilisateurs SSO ?
Donnez à vos utilisateurs SSO l'URL SSO de votre organisation Mist pour leur première connexion. Cette étape est nécessaire pour la première connexion uniquement, afin d’établir le compte en tant que compte SSO. Ensuite, ils peuvent utiliser l’URL SSO ou accéder directement au portail Mist Juniper (manage.mist.com). Pour plus d’informations sur la configuration des utilisateurs avec SSO, consultez Ajouter des fournisseurs d’identité et des utilisateurs.
Q : Comment puis-je savoir quels utilisateurs SSO ont accédé à mon organisation ?
R : Vous devez consulter les journaux d’audit sous l’onglet Organisation. Vous verrez un journal similaire à : Austin Powers austin@groovy.com Connectez-vous avec le rôle « Groove-Master »
Q : Est-ce que Mist possède un fichier de métadonnées ?
R : Oui, on peut trouver /api/v1/orgs/ :org_id/ssos/ :sso_id/metadata ou /metadata.xml.
Par exemple:
<md:EntityDescriptor xmlns:md="urn:oasis:names:tc:SAML:2.0:metadata" xmlns:ds="http://www.w3.org/2000/09/xmldsig#" entityID="https://saml-x6qlonl8.mist.com" validUntil="2032-03-29T00:44:08.503310+00:00"> <md:SPSSODescriptor AuthnRequestsSigned="false" WantAssertionsSigned="true" protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol"> <md:SingleLogoutService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location="https://api.mist.com/api/v1/saml/x6qlonl8/logout"/> <md:NameIDFormat> urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified </md:NameIDFormat> <md:AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location="https://api.mist.com/api/v1/saml/x6qlonl8/login" index="0" isDefault="true"/> <md:AttributeConsumingService index="0"> <md:ServiceName xml:lang="en-US">Mist</md:ServiceName> <md:RequestedAttribute Name="Role" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic" isRequired="true"/> <md:RequestedAttribute Name="FirstName" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic" isRequired="false"/> <md:RequestedAttribute Name="LastName" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic" isRequired="false"/> </md:AttributeConsumingService> </md:SPSSODescriptor> </md:EntityDescriptor>
Q : J’ai besoin de plusieurs SSO dans mon organisation. Est-ce que Mist prend en charge cela ?
R : Oui, absolument. Plusieurs SSO au sein d’une organisation sont pris en charge. Gardez à l’esprit qu’alors qu’une organisation peut avoir plusieurs SSO et qu’un utilisateur peut avoir des autorisations sur plusieurs organisations, un utilisateur SSO dans Mist ne peut « appartenir » qu’à un seul SSO. Cela est généralement plus pertinent lorsque vous avez un SSO « dev » et « production » et que vous utilisez la même adresse e-mail pour les deux.
Q : J’ai plusieurs organisations, puis-je utiliser l’SSO avec plusieurs organisations ?
R : Oui, c’est aussi possible. Il peut être géré de deux manières. D’abord, vous avez une organisation « d’origine » où vous avez le SSO. Ensuite, vous pouvez inviter manuellement des utilisateurs à votre deuxième organisation. Lorsqu’ils se connecteront, ils verront les deux organisations répertoriées. La deuxième façon consiste à utiliser notre fonctionnalité MSP (qui est une fonctionnalité d’accès contrôlé). Lorsque vous placez le SSO au niveau du MSP et en fonction du rôle retourné, les utilisateurs ont accès au MSP, ou seulement à des organisations spécifiques du MSP.
Q : Que se passe-t-il lorsque je supprime un SSO dans Mist ?
R : Lorsque vous supprimez un SSO, il supprimera automatiquement tous les comptes d’utilisateur dans Mist associés à ce SSO. Ceci est particulièrement utile lors d’une migration d’un SSO à un autre, par exemple de « dev » à « production ».
Q : Comment les jetons API fonctionnent-ils avec les utilisateurs SSO ?
R : Les utilisateurs de SSO peuvent utiliser des jetons API d’organisation. Les super-utilisateurs peuvent créer une API d’organisation avec les autorisations nécessaires. Les utilisateurs SSO ne prennent pas en charge les jetons d’API « basés sur l’utilisateur ». Vous pouvez également utiliser des comptes de service locaux selon les préférences du client.
Q : Ai-je besoin d’un utilisateur local dans Mist ?
R : Lorsque vous commencez à utiliser SSO, vous pouvez supprimer tous les comptes d’utilisateurs locaux précédemment créés dans Mist, sauf un. Il est recommandé de conserver un utilisateur local avec le rôle de super utilisateur pour vous assurer que vous ne serez pas bloqué hors de l’organisation en cas de problème avec le SSO. Étant donné qu'une personne ne peut pas utiliser une adresse e-mail pour SSO et un compte local, le compte local doit être configuré avec une adresse e-mail différente de celle qu'elle utilisera avec SSO. Par exemple, utilisez une adresse e-mail personnelle pour le compte local et utilisez l’adresse e-mail professionnelle pour le compte SSO. Pour plus d’informations sur les étapes de configuration des utilisateurs SSO, consultez Ajouter des fournisseurs d’identité et des utilisateurs.
Q : Pourquoi une erreur d’incompatibilité de certificat s’affiche-t-elle lors de la configuration de SSO ?
Une erreur d’incompatibilité de certificat se produit généralement lorsque le certificat du fournisseur d’identité (IdP) configuré dans Mist ne correspond pas au certificat utilisé par votre IdP pour signer les assertions SAML, ce qui entraîne des échecs d’authentification. Cette erreur se produit généralement en raison d’informations de certificat manquantes, de certificats expirés, de certificats incorrects ou de plusieurs certificats dans l’IdP. Pour résoudre ce problème :
- Téléchargez le bon certificat à partir de votre IdP et assurez-vous qu’il comprend le texte intégral avec les en-têtes et les pieds de page.
- Vérifiez que le certificat est valide. Si le certificat a expiré, générez-en un nouveau dans votre portail IdP et mettez à jour les détails dans le portail Mist.
-
Vérifiez si l’IdP a émis un nouveau certificat et mettez à jour les dernières informations sur le certificat dans le portail Mist.
En outre, il est important de conserver au moins un compte d’administrateur local dans Mist. Cela garantit un accès alternatif si SSO échoue en raison de problèmes liés aux certificats.
Q : Pourquoi un compte local n'est-il pas converti en compte SSO lors de l'authentification via l'IdP ?
Lorsque vous configurez l’authentification unique (SSO) et qu’un utilisateur se connecte via le fournisseur d’identité (IdP), Mist convertit automatiquement le compte de l’utilisateur d’un compte local en compte SSO. Toutefois, cette conversion n’a pas lieu si
-
L'adresse e-mail dans l'assertion IdP ne correspond pas exactement à l'adresse e-mail du compte de l'utilisateur dans Mist.
-
L’IdP n’envoie pas l’attribut correct (tel que l’ID de nom ou l’adresse e-mail) à Mist pour l’identification de l’utilisateur.
-
La même adresse e-mail est associée à un compte SSO d’une autre organisation.
-
L’utilisateur local a un rôle qui ne correspond pas correctement au rôle SSO.