SUR CETTE PAGE
Q : De quels attributs ai-je besoin pour envoyer mon assertion ?
Q : Comment puis-je résoudre les problèmes d’authentification unique ?
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 supporte cela ?
Q : Que se passe-t-il lorsque je supprime un SSO dans Mist ?
Q : Comment les jetons d’API fonctionnent-ils avec les utilisateurs d’authentification unique ?
Questions fréquentes sur l’authentification unique
Obtenez des réponses aux questions les plus fréquentes sur l'implémentation du SSO, Mist les exigences, le provisionnement, etc.
Q : Quelles sont les bases de l’implémentation de l’authentification unique de Mist que je devrais connaître ?
R : Mist prend en charge l’authentification unique basée sur SAML 2.0 dans plusieurs parties de notre produit, avec des implémentations identiques. Bien que ce document soit rédigé pour l’authentification unique de l’administrateur, nous prenons également en charge l’authentification unique pour l’accès invité, ainsi que l’auto-provisionnement PPSK où les implémentations sont les mêmes, à l’exception des attributs obligatoires. Ce document peut donc être appliqué à tous 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 pour Mist, et un compte SSO, ou un 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 mise en majuscule correcte des noms d’attributs.
Q : Quels IdP prennent Mist en charge pour l’accès SSO ?
R : Mist prend en charge tous les IdP qui prennent en charge SAML2.0.
Q : Est-ce que Mist prend en charge l’authentification unique initiée par les fournisseurs de services et les fournisseurs d’identité ?
R : Oui, Mist prend en charge l’authentification unique initiée par les fournisseurs de services et les fournisseurs d’identité. Avec la mise en garde que la toute première connexion d’un utilisateur SSO à Mist doit être initiée par IdP. Veuillez également noter que pour la connexion initiée par le fournisseur de services, l’ID d’entité entré dans l’IdP doit être identique à l’URL ACS.
Q : De quels attributs ai-je besoin pour envoyer mon assertion ?
R : Voici les attributs attendus par Mist dans l’assertion SAML :
Notez que les majuscules sont importantes.
- ID de nom
- Rôle
- Prénom
- Nom de famille
L’ID Nom est obligatoire. Le rôle est requis, sauf lorsque vous effectuez une configurationdefault_role
via l’API. FirstName et LastName sont recommandés, sinon vous verrez ? ? comme le nom et le prénom de l’utilisateur.
Q : Quels formats NameID prenez-vous en charge ?
R : NameID est utilisé comme identifiant unique de 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 configurez non spécifié dans la configuration de l’authentification unique Mist. Si vous utilisez non spécifié, vous pouvez nous envoyer presque n’importe quoi, tant qu’il est unique et cohérent. Vous verrez que nous générons un identifiant unique pour l’utilisateur dans Mist avec unspecified (non spécifié).
Q : À quoi sert un rôle ?
R : Le rôle est utilisé pour dériver l’autorisation qui doit être accordée à l’utilisateur. Le rôle renvoyé dans l’assertion correspondrait à un rôle dans la configuration du rôle d’authentification unique Mist sur la page Paramètres de l’organisation. Veuillez noter que l’autorisation de l’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 sur-ensemble des autorisations. Veuillez noter que, par défaut, tous les rôles doivent correspondre, sinon l’accès sera refusé à l’utilisateur. Pour permettre la correspondance partielle des rôles, une option d’API est ignore_unmatched_roles. Il existe également une option d’API default_role, lorsqu’aucun rôle n’est correspondant.
Nous acceptons plusieurs rôles dans une variété de formats dans l’assertion. Plusieurs rôles peuvent être envoyés sous forme de séparations par des virgules, de paires AttributeValue multiples ou avec l’analyse CN. En voici quelques exemples :
Attributs « Rôle » séparés par des virgules
<Attribute Name="Role"> <AttributeValue>"Employee,Mist,Developer"</AttributeValue> </Attribute>
# liste de rôles analysée
['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 de rôles analysée
['Employee', 'Mist', 'Developer']
Combinaison de paires AV séparées par des virgules et de plusieurs paires AV
<Attribute Name="Role"> <AttributeValue>"Employee,Mist"</AttributeValue> <AttributeValue>"Developer"</AttributeValue> </Attribute>
# liste de rôles analysée
['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 de rôles analysée
['Employee’, ‘Mist', 'Developer']
Q : Comment puis-je résoudre les problèmes d’authentification unique ?
R : Vous pouvez afficher les échecs en émettant cet appel d’API : {api_endpoint}/api/v1/orgs/ :{org_id}/ssos/ :{sso_id}/failures
Vous verrez le motif de l'échec ainsi que l'assertion qui a été reçue.
Pour émettre l'appel d'API, vous devez remplacer les termes en italique et 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 à partir de l'URL de votre portail Juniper Mist. L’URL du portail commence par gérer. L’URL du point de terminaison de l’API correspondante remplace manage par api. Notez les caractères en gras dans les exemples suivants.
URL du portail
manage.ac2.mist.com/admin/ ?org_id=xxxxxxx-xxxx-xxx
URL de point de terminaison d’API correspondante
api.ac2.mist.com/admin/ ?org_id=xxxxxxx-xxxx-xxx
-
{org_id}
Vous pouvez également trouver l’ID de votre organisation dans l’URL du portail Juniper Mist. L’ID apparaît après les caractères org_id=. Remarquez les caractères en gras dans l’exemple suivant.
ID de l’organisation dans l’URL du portail
manage.ac2.mist.com/admin/?org_id=12345678-1a2b-3456cdef-xyz123
- {sso_id}
Pour trouver votre ID SSO, envoyez cet appel d’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 n’en avez pas. L’accès pour les utilisateurs SSO est accordé à la demande par votre IdP. C’est-à-dire que les utilisateurs SSO sont authentifiés par l’IdP, mais Mist. Le niveau d’accès au tableau de bord Mist est contrôlé par l’attribut de rôle 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 d'authentification unique de votre organisation Mist pour la 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 Juniper Mist (manage.mist.com). Pour plus d’informations sur la configuration utilisateur avec l’authentification unique, 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 : Avez-Mist un fichier de métadonnées ?
R : Oui, il peut être trouvé /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 supporte cela ?
R : Oui, absolument. Plusieurs SSO au sein d’une organisation sont pris en charge. Gardez à l’esprit que, bien qu’une organisation puisse avoir plusieurs SSO et qu’un utilisateur puisse avoir des autorisations sur plusieurs organisations, un utilisateur SSO en Mist ne peut « appartenir » qu’à une seule SSO. Cela est généralement plus pertinent lorsque vous disposez d’un SSO « dev » et d’un SSO « production » et que vous utilisez la même adresse e-mail pour les deux.
Q : J’ai plusieurs organisations, puis-je utiliser l’authentification unique avec plusieurs organisations ?
R : Oui, c’est également possible. Il peut être géré de deux manières. Tout d’abord, vous avez une organisation « d’origine » où vous avez l’authentification unique. Ensuite, vous pouvez inviter manuellement des utilisateurs dans votre deuxième organisation. Lorsqu’ils se connectent, les deux organisations sont répertoriées. La deuxième méthode consiste à utiliser notre fonctionnalité MSP (qui est une fonction d’accès contrôlé). Dans ce cas, vous placez l’authentification unique au niveau du MSP et en fonction du rôle renvoyé, 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 supprime automatiquement tous les comptes d’utilisateur dans Mist associés à ce SSO. Ceci est particulièrement utile lors de la migration d’un SSO à un autre, par exemple « dev » vers « production ».
Q : Comment les jetons d’API fonctionnent-ils avec les utilisateurs d’authentification unique ?
R : Les utilisateurs SSO peuvent utiliser des jetons d’API d’organisation. Les super utilisateurs peuvent créer l’API de l’organisation avec les autorisations nécessaires. Les utilisateurs d’authentification unique ne prennent pas en charge les jetons d’API « basés sur l’utilisateur ». Vous pouvez également utiliser des comptes de service local en fonction des préférences du client.
Q : Ai-je besoin d’un utilisateur local dans Mist ?
R : Lorsque vous commencez à utiliser l’authentification unique, vous pouvez supprimer tous les comptes d’utilisateurs locaux précédemment créés dans Mist, à l’exception d’un seul. Il est recommandé de conserver un utilisateur local avec le rôle de super utilisateur pour vous assurer que vous n’êtes pas bloqué hors de l’organisation en cas de problème avec l’authentification unique. Étant donné qu'une personne ne peut pas utiliser une seule adresse e-mail à la fois pour l'authentification unique et pour un compte local, le compte local doit être configuré avec une adresse e-mail différente de celle qu'elle utilisera avec l'authentification unique. 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.