Configurer l'authentification Alteryx Server
Configurez la méthode d'authentification que vous souhaitez utiliser pour gérer l'accès à Server sur la page System Settings (Paramètres système) > Gallery Authentication (Authentification Galerie).
Commencez par sélectionner la méthode d'authentification que vous souhaitez utiliser pour Server. Passez ensuite aux étapes de configuration de la méthode sélectionnée.
Sélectionner le type d'authentification
Server prend en charge l'authentification intégrée, l'authentification Windows intégrée avec ou sans prise en charge de Kerberos et l'authentification SAML.
Built-in (Intégrée) : les utilisateurs indiquent une adresse e-mail et un mot de passe de leur choix pour accéder à Server.
Integrated Windows authentication (Authentification Windows intégrée) : les utilisateurs accèdent à Server avec des informations d'identification réseau internes.
Integrated Windows authentication with Kerberos (Authentification Windows intégrée avec Kerberos) : les utilisateurs accèdent à Server avec des informations d'identification réseau internes à l'aide des protocoles d'authentification Kerberos. Le processus de configuration de l'authentification Windows intégrée et de l'authentification Windows intégrée avec Kerberos est le même. Pour plus d'informations, reportez-vous à la section Terminer la configuration du type d'authentification choisi et sélectionnez Configurer l'authentification Windows intégrée.
SAML authentication (Authentification SAML) : les utilisateurs accèdent à Server avec des informations d'identification de fournisseur d'identité (IDP).
Avertissement
Server ne prend pas en charge la modification du type d'authentification après la configuration. Cela pourrait compromettre ses fonctionnalités. Si vous souhaitez modifier le type d'authentification, contactez votre équipe de compte pour discuter des possibilités d'assistance.
Terminer la configuration du type d'authentification choisi
La configuration pour chaque type d'authentification varie. Sélectionnez le type d'authentification que vous avez choisi et suivez les étapes pour terminer la configuration.
Étape 1. Définir un administrateur Galerie par défaut pour l'authentification intégrée
Après avoir sélectionné l'authentification Built-in ((Intégrée), créez un administrateur Galerie par défaut au bas de la page Gallery Authentication (Authentification de la Galerie). L'administrateur Galerie (Server) gère les utilisateurs, les workflows, etc. Pour l'authentification Built-in (Intégrée), saisissez l'adresse e-mail de l'administrateur.
Complétez les écrans restants dans les paramètres système (accédez aux pages d'aide Interface utilisateur Server et Moteur pour plus d'informations sur ces écrans), puis sélectionnez Finish (Terminer).
Étape 2. Terminer la création du compte administrateur Galerie
Pour terminer la création du compte d'administrateur Galerie, accédez à la page de connexion de Server. Pour ce faire, sélectionnez le lien vers le Server affiché sur la page System Settings (Paramètres système) > Status (Statut) ou entrez l'URL de Server dans votre navigateur Internet.
Sélectionnez Se connecter.
Sur la page de connexion, sélectionnez S'inscrire à un nouveau compte.
Saisissez un prénom et un nom, puis sélectionnez un fuseau horaire dans le menu déroulant.
Dans Email (E-mail), saisissez l'adresse e-mail que vous avez fournie pour le paramètre Default Gallery Administrator (Administrateur Galerie par défaut) sur la page Paramètres système > Gallery Authentication (Authentification de la Galerie).
Dans Password (Mot de passe), créez un mot de passe de compte. Votre mot de passe doit contenir :
Au moins 8 caractères
Au moins 1 lettre
Au moins 1 chiffre
Des majuscules et des minuscules
Au moins 1 caractère spécial
Sélectionnez S'inscrire.
Vous êtes maintenant connecté en tant qu'administrateur Galerie (Server). Les informations d'identification que vous avez saisies dans le formulaire d'inscription sont enregistrées comme vos informations d'identification pour la suite. Vous êtes maintenant prêt à ajouter des utilisateurs Server. Accédez à la page Ajouter des utilisateurs Server.
Important
Si vous utilisez AWS avec l'authentification Windows, la connexion TCP doit conserver le même port source pour rester authentifiée. Pour cette raison, nous vous recommandons d'utiliser l'équilibreur de charge réseau ou classique plutôt que l'équilibreur de charge application (Application load balancer).
Note
La différence dans la configuration de l'authentification Windows intégrée et celle de l'authentification Windows intégrée avec Kerberos est le protocole utilisé pour authentifier les utilisateurs avec Active Directory. L'option authentification Windows intégrée utilise NTLM tandis que l'authentification Windows intégrée avec Kerberos remplace NTLM par Kerberos.
Aucune configuration particulière n'est nécessaire sous Server lui-même, mais l'option Kerberos nécessite la présence d'un domaine Kerberos et d'un KDC correctement configurés dans le domaine Active Directory.
Étape 1. Définir un administrateur Galerie par défaut pour l'authentification Windows
Après avoir choisi l'authentification Integrated Windows authentication (Authentification Windows intégrée), créez un administrateur Galerie par défaut au bas de la page Gallery Authentication (Authentification de la Galerie). L'administrateur Galerie (Server) gère les utilisateurs, les workflows, etc. Pour l'authentification Windows intégrée, saisissez le compte utilisateur au format : domaine\nom d'utilisateur.
Complétez les écrans restants dans les paramètres système (accédez aux pages d'aide Interface utilisateur Server et Moteur pour plus d'informations sur ces écrans), puis sélectionnez Finish (Terminer).
Étape 2. Accéder à Server
L'administrateur Galerie (Server) par défaut peut désormais accéder à Server. Pour ce faire, sélectionnez le lien vers le Server affiché sur la page System Settings (Paramètres système) > Status (Statut) ou entrez l'URL de Server dans votre navigateur Internet. Vous êtes maintenant connecté en tant qu'administrateur Galerie (Server) et prêt à ajouter des utilisateurs Server. Accédez à la page Ajouter des utilisateurs Server.
Prise en charge de plusieurs domaines
Server prend en charge plusieurs domaines pour l'authentification Windows. Vous n'avez pas besoin de configurer quoi que ce soit dans Server pour l'activer, mais ces capacités et autorisations doivent être présentes dans les domaines.
Le domaine sur lequel Server s'exécute doit avoir la même stratégie de confiance que les autres utilisateurs du domaine pour qu'Active Directory puisse résoudre et déterminer les autorisations utilisateur.
Les deux domaines doivent faire partie de la même forêt.
Alteryx service doit pouvoir lire tous les attributs des conteneurs CN=Users et CN=Computers pour les deux domaines. Alteryx service s'exécute sous le compte du système local du serveur sur lequel il est installé. Si vous définissez un compte de service dédié au lieu d'utiliser le système local, le compte doit avoir l'autorisation de lire tous les attributs des deux conteneurs pour activer l'authentification pour les deux domaines.
Pour configurer l'authentification SAML pour le SSO (Single Sign On), votre fournisseur d'identité (IDP) doit prendre en charge SAML.
Important
Avant de configurer l'authentification SAML pour Server, vous devez l'ajouter en tant que fournisseur de services dans l'IDP. L'IDP peut avoir besoin des éléments suivants :
l'URL de base ACS (par exemple, http://localhost/webapi/Saml2/Acs) ;
l'ID de l'entité SP (par exemple, http://localhost/webapi/Saml2).
À partir de la version 2022.3, nous utilisons des points de terminaison de fournisseurs de services mis à jour via le service API Web. Les configurations existantes utilisant les points de terminaison précédents continuent de fonctionner et aucune action n'est requise à ce stade pour continuer à utiliser SAML dans votre système Alteryx Server existant. Pour plus d'informations, consultez les Notes de publication Server 2022.3.
L'IDP peut également exiger que vous fassiez correspondre les déclarations d'attributs email, firstName et lastName aux champs correspondants de celui-ci pour authentifier les utilisateurs.
Le certificat de signature IDP doit être configuré avec un algorithme de signature SHA-256 ou supérieur.
Sélectionnez une option pour obtenir les métadonnées requises par l'IDP. Vous pouvez configurer SAML à l'aide d'une URL de métadonnées IDPou d'un certificat X509 et d'une URL SSO IDP.
Terminez la configuration de l'IDP SAML.
ACS Base URL (URL de base ACS) : URL du service ACS (Assertion Consumer Service) qui accepte les messages SAML pour établir une session.
IDP URL (URL d'IDP) : URL de l'application Alteryx configurée dans l'IDP, également appelée ID d'entité IDP.
IDP Metadata URL (URL des métadonnées d'IDP) : URL fournie par l'IDP qui inclut l'URL SSO IDP et le certificat X509 pour la configuration du service d'authentification Alteryx.
IDP SSO URL (URL SSO de l'IDP) : URL SSO, fournie par l'IDP, utilisée par le service d'authentification Alteryx pour se connecter à l'IDP.
X509 certificate (Certificat X509) : certificat public fourni par l'IDP pour une communication sécurisée avec le service d'authentification Alteryx.
Enable Request Signing (Activer la signature de demande) : pour les IDP qui requièrent la signature de demande, vous pouvez activer ce paramètre. Ce paramètre nécessite l'installation d'un certificat signé valide avec une clé privée RSA associée dans le magasin de certificats Windows.
SSL/TLS Certificate Hash (Hachage de certificat SSL/TLS) : une fois votre certificat et votre clé privée installés, fournissez le hachage unique du certificat SSL/TLS.
Verify IDP (Vérifier l'IDP) : sélectionnez cette option pour ouvrir une fenêtre de navigateur, vous connecter, tester la configuration IDP et définir l'administrateur Server par défaut.
Définir un administrateur Galerie par défaut pour SAML
Un compte d'administrateur galerie (Server) doit être créé pour administrer le site (gérer les utilisateurs, les workflows, etc.). Pour l'authentification SAML, sélectionnez Verify IDP (Vérifier l'IDP) afin de tester la configuration IDP et de remplir le champ avec les informations d'identification IDP.
Vous êtes maintenant connecté en tant qu'administrateur Server. Vous êtes maintenant prêt à ajouter des utilisateurs Server. Accédez à la page Ajouter des utilisateurs Server.
Note
Les administrateurs peuvent synchroniser l'accès des utilisateurs et des groupes à Server à l'aide d'Azure Active Directory (Azure AD) et du protocole SCIM. Cela permet aux administrateurs de gérer les autorisations des utilisateurs et des groupes et l'accès à Server avec leur fournisseur d'identité comme source unique d'informations fiables. La synchronisation des utilisateurs et des groupes d'Azure AD vers Server est automatique. Cela permet d'intégrer ou de désactiver plus rapidement de nouveaux utilisateurs de Server.
Cette fonctionnalité est disponible pour les clients qui utilisent SAML comme méthode d'authentification. Tout fournisseur d'identité prenant en charge SCIM peut utiliser cette fonctionnalité. Notez que nous avons officiellement testé et pris en charge Azure AD.
Pour en savoir plus sur les paramètres SCIM, consultez la page Paramètres Alteryx Server.
Pour plus d’informations sur la configuration de Alteryx Server pour SCIM avec Azure Active Directory, reportez-vous à la rubrique configurer Alteryx Server pour SCIM avec Azure Active Directory.
Pour plus d'informations sur Azure SCIM, consultez la documentation Microsoft Azure.
Pour plus d'informations sur le déploiement et le test de votre point de terminaison SCIM dans Azure, consultez Tutoriel : développement d'un exemple de point de terminaison SCIM dans Azure Active Directory.
Consultez ces réponses aux questions les plus fondamentales sur Azure SCIM et Alteryx Server :
Une fois SCIM activé, toutes les entités d'Azure (ou d'autres fournisseurs d'identité) se synchroniseront avec Server, et les modifications futures apportées à ces entités entraîneront des modifications aux objets associés dans Server. Les utilisateurs et les groupes présents dans Server qui figurent aussi dans le fournisseur d'identité seront liés et mis à jour en fonction des modifications apportées à celui-ci. Le fournisseur d'identité agit comme une source d'informations fiables pour ces objets. Par exemple, si l'utilisateur Jean Dupont existe dans les deux systèmes et que vous avez activé SCIM, si vous remplacez Jean Dupont par Jean Dubois dans Server, la prochaine synchronisation rétablira l'utilisateur Jean Dupont.
Les groupes sont liés par nom et les utilisateurs par e-mail.
Les utilisateurs et les groupes locaux qui n'existent que dans Server sont hors du champ d'application du fournisseur d'identité et resteront en tant qu'objets gérés par Server.
Certains caractères peuvent ne pas être transférés de SCIM à Server : cela dépend du fournisseur d'identité. Si le fournisseur d'identité autorise des caractères spéciaux, restreints ou réservés dans le nom d'objet d'un groupe ou d'un utilisateur, le caractère est synchronisé vers Server. Nous n'autorisons ni n'interdisons explicitement aucun caractère pour ces noms d'objet.
Server n'établit pas de connexion au fournisseur d'identité pour SCIM. À la place, il fournit un certain nombre de points de terminaison d'API et un jeton d'accès que le fournisseur d'identité utilise pour établir une connexion à Server. Ces points de terminaison peuvent être testés manuellement à l'aide d'outils de test API standard tels que Postman.
Toutes les modifications apportées aux objets utilisateur et groupe sont auditées via les journaux d'audit de Server. Cela inclut les modifications apportées par SCIM.
SCIM ne met pas à jour la propriété, les rôles ou les autorisations des ressources. Par conséquent, tous les utilisateurs et groupes existants conservent les ressources dont ils sont actuellement propriétaires, ainsi que les rôles et autorisations qui leur sont attribués.
Les paramètres du groupe Server déterminent les autorisations. Azure Active Directory ne stocke pas les autorisations.
Lorsque vous synchronisez un groupe AD depuis Azure vers Server, les administrateurs peuvent définir des autorisations pour ce groupe nouvellement créé dans Server. Ensuite, lorsque vous ajoutez un nouvel utilisateur à ce groupe AD, SCIM ajoute automatiquement cet utilisateur au groupe Server. L'utilisateur obtient ensuite des autorisations en fonction de ce groupe Server.
La fonctionnalité SCIM inclut uniquement l'octroi d'accès aux utilisateurs et aux groupes Server à partir d'Azure AD. Cette synchronisation n'inclut pas d'autorisations pour d'autres ressources d'Azure, telles que les bases de données. Les utilisateurs devront toujours utiliser des connexions aux données DCM ou Server pour toutes les données.
Si vous devez restaurer une version antérieure de Server qui n'inclut pas SCIM, ce dernier ne fonctionnera pas et ne sera pas disponible tant que Server n'aura pas été mis à niveau une nouvelle fois.
Si vous devez restaurer une sauvegarde de base de données à un moment antérieur à la configuration de SCIM, reconfigurez SCIM après la restauration et effectuez la synchronisation initiale.
Si vous devez restaurer une sauvegarde sur une version de Server qui utilise SCIM, effectuez une resynchronisation complète du côté du fournisseur d'identité, pour que notre base de données soit à nouveau synchronisée avec celui-ci.
Lorsque vous désactivez un utilisateur à l'aide de SCIM, les planifications fonctionneront comme elles le font actuellement lorsque vous désactivez ou supprimez un utilisateur. Elles fonctionneront de la même manière que si vous aviez désactivé l'utilisateur depuis l'interface utilisateur de Server ou l'API ou si vous l'aviez supprimé depuis l'API. Pour plus d'informations, consultez la section Désactiver un utilisateur.
Les délais de synchronisation varient en fonction du fournisseur d'identité et sont configurables. Pour Azure, les synchronisations peuvent prendre jusqu'à 40 minutes. Cette valeur est statique et ne peut pas être configurée.
Nous avons effectué des tests approfondis avec Azure et des tests limités avec Okta. Toutefois, nous n'avons pas pu tester l'agent d'approvisionnement Okta, car il n'est fourni que pour la version payante. Les autres fournisseurs d'identité devraient fonctionner, mais n'ont pas été testés.