Configuration d’identité

Dans Admin Console, un répertoire est une entité qui contient des ressources (comme des utilisateurs) et des règles (comme l’authentification). Ces répertoires sont semblables aux annuaires LDAP ou Active Directory.

Fournisseur d’identité de l’organisation, par exemple Active Directory, Azure, Ping, Okta, InCommon ou Shibboleth.

Créé, détenu et géré par l’utilisateur final. Adobe se charge de l’authentification, tandis que l’utilisateur final gère l’identité proprement dite. Les utilisateurs gardent un contrôle total sur les données et les fichiers associés à leur ID. Ils peuvent également acheter des produits et services supplémentaires auprès d’Adobe. Les administrateurs peuvent inviter des utilisateurs à devenir membre d’une organisation, mais aussi les supprimer à tout moment. Néanmoins, un utilisateur ne peut pas être exclu de son compte d’Adobe ID. L’administrateur ne peut pas prendre le pouvoir sur les comptes ni les supprimer. Vous pouvez commencer à utiliser les Adobe ID directement, sans configuration particulière.

Voici quelques conditions et situations pour lesquelles un Adobe ID est recommandé :

• Si vous souhaitez permettre aux utilisateurs de créer, posséder et gérer leur propre identité.
• Si vous souhaitez permettre aux utilisateurs d’acheter d’autres produits et services Adobe ou de s’y abonner.
• Si les utilisateurs sont amenés à utiliser d’autres services Adobe, qui ne prennent actuellement pas en charge les Enterprise ID ou Federated ID.
• Si les utilisateurs ont déjà des Adobe ID, ainsi que des données associées telles que des fichiers, des polices ou des paramètres. 
• Dans le cadre universitaire, où les étudiants peuvent conserver leur Adobe ID après avoir terminé leurs études.
• Si vous avez des sous-traitants ou des indépendants qui n’utilisent pas des adresses électroniques relatives aux domaines que vous contrôlez.
• Si vous disposez d’un contrat d’équipe Adobe, vous devrez utiliser ce type d’identité.

Créé, détenu et géré par une organisation. Adobe héberge l’Enterprise ID et effectue l’authentification, mais c’est l’organisation qui le met à jour. Les utilisateurs finaux ne peuvent pas s’abonner avec un Enterprise ID, en créer un, ni souscrire à des produits et services supplémentaires auprès d’Adobe avec un Enterprise ID.

Seul un administrateur peut créer un Enterprise ID, puis l’attribuer à un utilisateur. Il peut révoquer l’accès aux produits et services en prenant le contrôle du compte, ou bien supprimer définitivement l’Enterprise ID afin de bloquer l’accès aux données qui y sont associées.

Voici quelques conditions et situations pour lesquelles un Enterprise ID est recommandé :

• Si vous devez conserver une maîtrise totale des applications et services mis à la disposition d’un utilisateur.
• Si vous avez besoin d’un accès en urgence aux fichiers et données associés à un ID.
• Si vous devez avoir la possibilité de bloquer ou de supprimer entièrement un compte d’utilisateur.

Créé et détenu par une organisation, et lié au répertoire de l’entreprise via la fédération. L’organisation gère les informations d’identification et traite l’authentification unique via un fournisseur d’identité (IdP) SAML2.

Voici quelques conditions et situations pour lesquelles un Federated ID est recommandé :

• Si vous souhaitez fournir des utilisateurs suivant l’annuaire d’entreprise de votre organisation.
• Si vous souhaitez gérer l’authentification des utilisateurs.
• Si vous devez conserver une maîtrise totale des applications et services mis à la disposition d’un utilisateur.
• Si vous souhaitez permettre aux utilisateurs d’utiliser la même adresse e-mail pour s’inscrire et obtenir un Adobe ID.

Partie d’une adresse électronique placée après le symbole @. Pour utiliser un domaine avec un Enterprise ID ou un Federated ID, vous devez d’abord confirmer que vous en êtes le propriétaire.

Par exemple, une organisation possède plusieurs domaines (geometrixx.com, support.geometrixx.com, contact.geometrixx.com) mais ses employés s’authentifient sur geometrixx.com. Dans ce cas, l’organisation utilise le domaine geometrixx.com pour configurer l’identité des utilisateurs dans Admin Console.

• Collabore avec les managers de répertoire IdP et les managers DNS pour configurer les identités dans Admin Console. Ce document s’adresse aux administrateurs système qui ont accès à Admin Console. Ces personnes sont amenées à travailler avec d’autres qui (généralement) n’ont pas accès à Admin Console.

• Met à jour les jetons DNS pour valider la propriété d’un domaine.

• Crée des connecteurs dans l’IdP.

L’identité de chaque utilisateur est vérifiée par rapport à une source d’authentification. Pour utiliser des Enterprise ID ou des Federated ID, configurez votre propre source d’authentification en ajoutant un domaine. Par exemple, si votre adresse électronique est antoine@exemple.com, exemple.com correspond à votre domaine. Le fait d’ajouter un domaine permet de créer des Enterprise ID ou Federated ID dotés d’adresses e-mail sur le domaine. Un domaine peut être utilisé avec des Enterprise ID ou des Federated ID, mais pas avec les deux. Vous pouvez toutefois ajouter plusieurs domaines.

Une organisation doit prouver qu’elle contrôle un domaine. Elle peut également ajouter plusieurs domaines. En revanche, un domaine ne peut être ajouté qu’une seule fois. Les domaines publics connus et généraux, comme gmail.com ou yahoo.com, ne peuvent pas être ajoutés.

Pour en savoir plus sur les types d’identité, consultez la section Gestion des types d’identité.

Votre répertoire est créé.

Si vous avez opté pour un répertoire avec le type d’identité Enterprise ID, vous avez terminé. Vous pouvez maintenant configurer vos domaines dans Admin Console.

Si vous avez opté pour un répertoire avec le type d’identité Federated ID, Adobe devra le mettre en service avant que vous puissiez procéder à la moindre opération dessus. Néanmoins, inutile d’attendre sans rien faire : entre temps, vous pouvez configurer vos domaines dans Admin Console.

Une fois qu’Adobe vous a confirmé par e-mail que votre répertoire était mis en service, configurez les paramètres SAML qui lui sont associés.

Lorsqu’une organisation configure et active l’authentification unique (SSO), ses utilisateurs peuvent se servir de leurs informations d’identification d’entreprise pour accéder aux logiciels Adobe. Ainsi, ils peuvent utiliser un identifiant unique pour accéder aux applications pour postes de travail, aux services et aux applications mobiles Adobe.

Le portail Adobe Admin Console propose aux utilisateurs de l’entreprise une méthode leur permettant de s’authentifier en utilisant leur identité d’entreprise existante. Les Federated ID Adobe permettent l’intégration avec un système de gestion des identités par authentification unique (SSO). L’authentification unique est activée à l’aide du protocole SAML, un protocole normalisé qui connecte les systèmes de gestion des identités aux prestataires de services Cloud tels qu’Adobe.

L’authentification unique permet d’échanger en toute sécurité les informations d’authentification entre les différentes parties, le prestataire de services (Adobe) et le fournisseur d’identité (IdP). Le prestataire de services envoie une demande à l’IdP, qui essaie d’authentifier l’utilisateur. Si l’authentification réussit, l’IdP envoie un message de réponse afin de connecter l’utilisateur.

Pour configurer l’authentification unique pour les logiciels d’Adobe, les administrateurs informatiques ont besoin des éléments suivants :

• Une bonne compréhension de SAML 2.0
• Un fournisseur d’identité (IdP) prenant en charge le protocole SAML 2.0 et ayant au minimum :
  • Un certificat IDP
  • Une URL de connexion IDP
  • Une liaison IDP Post ou Redirection HTTP
  • Une URL ACS (Assertion Consumer Service)
• Un accès à la configuration DNS pour le traitement de déclaration de domaine

L’URL de connexion du fournisseur d’identité (IdP) n’a pas besoin d’être accessible en externe pour que les utilisateurs puissent y accéder afin d’ouvrir une session. En revanche, si elle est accessible uniquement via le réseau interne de l’entreprise, les utilisateurs ne pourront ouvrir une session dans les produits Adobe que s’ils sont connectés au réseau interne de l’entreprise (directement, en wi-fi ou par VPN). Il n’est pas nécessaire que la page de connexion soit accessible uniquement en HTTPS, mais c’est conseillé pour des raisons de sécurité.

Les services cloud d’Adobe proposent l’authentification unique à l’aide d’un connecteur SaaS SAML 2.0 fourni par Okta. Le connecteur est utilisé pour communiquer avec votre fournisseur d’identité afin de proposer des services d’authentification. Vous n’êtes pas obligé d’utiliser Okta comme service de fournisseur d’identité car Okta est connecté à de nombreux fournisseurs de services d’identité SAML 2.0. Pour plus d’informations, consultez la section Authentification unique (SSO) / Questions fréquentes.

Si votre entreprise souhaite tester l’intégration de l’authentification unique, il est recommandé de déposer un domaine de test dont vous êtes propriétaire, tant que votre entreprise possède un fournisseur d’identité avec des identités définies dans ce domaine de test. Cela vous permet de tester l’intégration avant de déposer les principaux domaines, jusqu’à ce que vous vous sentiez à l’aise avec le processus de dépôt de domaine et de configuration.

Si vous avez déjà un fournisseur d’identité (IdP), vous pouvez facilement définir votre configuration SSO à l’aide du connecteur SaaS SAML 2.0 fourni par Okta.

Votre répertoire est maintenant configuré pour l’authentification unique.

Si ce n’est pas déjà fait, vous pouvez ajouter des domaines dans Admin Console. Si c’est fait, vous pouvez associer les domaines requis à ce répertoire.

Les domaines que vous ajoutez à Admin Console ne doivent pas forcément être enregistrés auprès du même IdP. En revanche, lorsque vous associez les domaines à un répertoire, chaque domaine d’un IdP spécifique doit être associé à un répertoire spécifique.

Vous ne pouvez pas ajouter un domaine dans Admin Console s’il a déjà été ajouté dans le portail Admin Console d’une autre organisation. En revanche, vous pouvez demander à y avoir accès.

Vos domaines sont maintenant ajoutés dans Admin Console. Cependant, vous devez encore prouver que vous en êtes le propriétaire.

Une organisation doit prouver qu’elle possède un domaine. Elle peut ajouter autant de domaines que nécessaire dans Admin Console.

Admin Console permet à chaque organisation d’utiliser un seul jeton DNS pour prouver la propriété de tous ses domaines. Par ailleurs, Admin Console n’exige pas de validation DNS pour les sous-domaines. Cela signifie que lorsque vous utilisez le jeton DNS et prouvez la propriété d’un domaine, tous les sous-domaines qui lui sont associés sont instantanément validés dès leur ajout dans Admin Console.

Plusieurs fois par jour, Admin Console tente de valider les domaines que vous avez ajoutés. Il est donc inutile d’intervenir pour valider un domaine une fois que les jetons DNS sont correctement configurés.

Si vous devez valider votre domaine immédiatement, vous pouvez le faire dans Admin Console. Pour valider manuellement vos domaines :

À présent, vous pouvez associer les domaines validés aux répertoires requis dans Admin Console.

Si vous ajoutez des domaines existants dans Admin Console, vous recevez le message suivant :

Si vous demandez l’accès à ce domaine, votre nom, votre adresse e-mail et le nom de votre organisation seront communiqués aux administrateurs système de l’organisation propriétaire.

Le type de répertoire (Enterprise ou Federated) dépend de la façon dont il a été configuré par l’organisation propriétaire. Cela signifie que vous devez, dans tous les cas, utiliser le type de répertoire sélectionné par l’organisation propriétaire.

Dans la mesure où le domaine a déjà été configuré par le propriétaire (voir le paragraphe « Prouver la propriété d’un domaine » dans la section Configuration de domaines), en tant que mandataire, vous n’avez rien à faire de plus. Une fois que la demande d’accès est acceptée par le propriétaire, votre organisation a accès au répertoire et à l’ensemble de ses domaines, tels qu’ils ont été configurés par l’organisation propriétaire.

Si votre demande d’accès au répertoire est acceptée par l’organisation propriétaire, vous recevez une notification par e-mail. Votre demande de mandat disparaît alors, elle est remplacée par le répertoire faisant l’objet du mandat, ainsi que ses domaines, avec le statut Actif (sous mandat) dans vos listes Répertoires et Domaines.

Vous pouvez à présent ajouter des utilisateurs finaux et des groupes d’utilisateurs, puis les affecter à des profils de produit.

En tant qu’organisation mandataire, si vous n’avez plus besoin d’avoir accès au répertoire sous mandat, vous pouvez retirer votre statut de mandataire à tout moment.

Si vous retirez votre droit d’accès à un répertoire sous mandat, les utilisateurs Enterprise ID ou Federated ID qui appartiennent aux domaines de ce répertoire (c’est-à-dire qu’ils se connectent avec les identifiants du domaine) sont également retirés de votre organisation. En outre, ces utilisateurs perdront l’accès à tous les logiciels qui leur sont conférés par votre organisation.

Un e-mail de notification est envoyé aux administrateurs système des organisations mandataires.

Vous pouvez également choisir de refuser la demande d’accès à un répertoire que vous détenez.

Le motif que vous fournissez est transmis par e-mail à l’organisation à l’origine de la demande. Toutefois, votre e-mail, votre nom et les informations sur votre organisation ne sont pas divulgués.

Vous pouvez révoquer l’accès d’une organisation mandataire à laquelle vous avez précédemment donné accès.

Si vous révoquez l’accès d’une organisation mandataire, les utilisateurs dotés de comptes Enterprise ID ou Federated ID associés à un domaine du répertoire concerné sont retirés de l’organisation mandataire. Ces utilisateurs perdent également l’accès à tous les logiciels ou services qui leur sont conférés par l’organisation mandataire.

Vous avez la possibilité de révoquer la clé de chiffrement dédiée d’un répertoire.