Fédération d'identité

AFFICHER TOUT LE CONTENU

Table des matières

Introduction

Octopus peut se connecter à un fédérateur d’authentification pour faciliter l'accès à l'application en mode hébergé.

L'authentification unique peut être utilisée de manière indépendante pour les composantes suivantes, selon ce qui est supporté avec votre fédérateur: 

  • Le portail Web destiné aux utilisateurs finaux.
  • Les applications destinées aux intervenants (le client Windows WinUI, WebTech).
AVERTISSEMENT :

Avant de considérer cette fonctionnalité, il faut s'assurer d’avoir les ressources disponibles ayant l'expertise pour mettre en place et supporter celle-ci.

L’expertise requise pour la mise en place de service d’authentification fédéré dépasse l’expertise d’Octopus.

 

NOTE : Octopus-ITSM ne gère qu’une « Application d’entreprise », donc un seul « Tenant ». Toutefois, le mode 128 permet l’authentification sur plus d’un domaine.

Préalables

Pour effectuer la mise en place de l'authentification intégrée, au préalable avoir une infrastructure de fédération répondant aux exigences suivantes :

  • Utiliser un système de fédération d’identité supporté par Octopus;
    • Active Directory Federation Services 3.0 / 4.0 (AD FS)
      • Toutes les applications Octopus sont supportées par ce système de fédération
        • Application destinée aux utilisateurs finaux 
          • Portail Web
        • Applications destinées aux intervenants
          • WinUI
          • WebTech
    • Fédération d'identité - Microsoft Entra ID
      • Toutes les applications Octopus sont supportées par ce système de fédération
        • ​Application destinée aux utilisateurs finaux 
          • Portail Web
        • Applications destinées aux intervenants
          • WinUI
          • WebTech

  • Effectuer la configuration technique appropriée
    • Rendre votre fédérateur d’identité visible sur le Web.
    • Activer les points de terminaisons requis pour les applications souhaitées.
    • Configurer votre fédérateur d’identité pour supporter les relying party requis.
    • Utiliser un certificat SSL signé par une autorité de certification publiquement reconnu.
      • Cette étape est primordiale afin que le client Octopus puisse se connecter sans avoir à établir une connexion à un réseau privé virtuel (VPN) vers votre environnement.
  • Ajuster vos processus de manière à supporter votre utilisation des identités fédérées.
    • Assurer la correspondance entre les identités Octopus et les identités fédérées.
    • Configurer les postes de travail pour supporter l’authentification intégrée.

Les possibilités de configuration des différents fédérateurs d’identités étant infinies, Octopus ne peut s’engager à offrir du soutien pour la mise en œuvre de ces exigences; il faut s'assurer d’avoir à l’interne une ressource ayant les connaissances techniques nécessaires.

Fonctionnement de l’authentification intégrée

Lorsque le mode d’authentification intégré est en place, Octopus n'est plus responsable d'authentifier les usagers.

Lorsqu'un utilisateur tente de se connecter, le serveur Octopus va rediriger la requête d'authentification vers votre serveur d’authentification, et attendre que celui-ci lui fournisse un jeton de session (session token).

Le système de l'utilisateur va ensuite utiliser le jeton de session pour s'identifier automatiquement auprès d'Octopus. Dans le cas où un utilisateur soit reconnu par votre fédérateur d'identité, mais inexistant dans votre Octopus, celui-ci sera automatiquement créé, assigné au groupe par défaut Utilisateur final (Portail Web) et aura accès à votre Portail Web.

Chaque application utilise des points de terminaisons différents, qui doivent être correctement configurés :

  • Configuration générale
    • Federation Metadata [/FederationMetadata/2007-06/FederationMetadata.xml].
  • Portail Web
    • SAML2.0/WS-Federation [/adfs/ls ou /wsfed].
  • WinUI
    • WS-Trust 1.3 - Kerberos [/adfs/service/trust/13/kerberosmixed].
    • WS-Trust 1.3 - Password [/adfs/services/trust/13/usernamemixed].
  • Octopus 5
    • OAuth2 [/adfs/oauth2/authorize].
    • OAuth2 [/adfs/oauth2/token].

Le jeton de session fourni à Octopus par votre fédérateur d'identité devra contenir les réclamations (claims) suivantes :

  • name
    • Correspond au champ Nom d'utilisateur Windows dans Octopus.
    • Est le champ utilisé pour établir la correspondance entre votre fédérateur d'identité et Octopus.

    • Correspond normalement à l'attribut sAMAccountName de votre Active Directory. Dans le contexte d'Azure AD, on doit plutôt considérer le uniquePrincipalName de votre Active Directory.
    • Cette réclamation est obligatoire.
  • givenname
    • Correspond au champ Prénom dans Octopus.
    • Correspond normalement à l'attribut givenName dans Active Directory.
    • Cette réclamation est obligatoire, mais n'est pas validée.
  • surname
    • Correspond au champ Nom dans Octopus.
    • Correspond normalement à l'attribut sn dans Active Directory.
    • Cette réclamation est obligatoire, mais n'est pas validée.
  • emailaddress
    • Correspond au champ Courriel professionnel dans Octopus.
    • Correspond normalement à l'attribut mail dans Active Directory.
    • Cette réclamation est optionnelle et n'est pas validée.

Configuration Octopus

Une fois votre fédération d’identité en place, il faut suivre cette procédure afin de finaliser la mise en place avec Octopus.

L’activation de l’authentification intégrée n’est disponible que si vous avez configuré votre serveur de fédération de service et testé celui-ci.

Seul un administrateur Octopus ayant les accès suivants pourra compléter la configuration Octopus:

  • Général - Administrer Octopus.
  • Général - Modifier les données communes à toutes les équipes.
  • Applications - Accéder à Octopus.
  • Applications - Accéder à WebTech.
  • Application - Accéder au portail Web.

Pour lancer la configuration, utilisez le menu Outils > Configuration de fédération d’identité

Voir en image

 

Dans la fenêtre Configuration de fédération d’identité se trouve le lien fournissant le Metadata de votre environnement afin de configurer un Relying Party destiné à votre serveur ADFS. Il est normal que cette URL ne soit pas accessible directement.

Vous pourrez entrer l’adresse du Metadata de fédération pour en vérifier la compatibilité. La vérification de la compatibilité effectue une connexion sur le service de Metadata pour déterminer les points de terminaisons fonctionnels compatibles avec votre choix de fédérateur, avant de tester chacun d’eux.

Une fois la vérification complétée, vous pourrez activer le mode d’authentification des utilisateurs (Portail Web) ou le mode d’authentification des applications pour intervenants (WinUI, WebTech et Octopus 5).

Configuration pour Active Directory Federation Services 3.0 / 4.0

De manière générale, les Relying Party ADFS doivent répondre aux critères suivants :

  • Créer un Relying Party pour chacun des environnements que vous utilisez (production, test).
    • https://nomclient.octopus-itsm.com.
    • https://nomclient-test.octopus-itsm.com.
  • Créer un Relying Party manuellement pour chaque URL patrimoniale que vous utilisez. Si vous n’utilisez pas d’URL patrimoniale, vous n’avez pas à créer ceux-ci.
    • https://app.octopus-itsm.com.
    • https://app1.octopus-itsm.com.
    • https://app3.octopus-itsm.com.
    • https://app4.octopus-itsm.com.
  • Chaque Relying Party ne doit référer qu’à un seul point de terminaison (endpoints).
  • Chaque Relying Party doit utiliser le protocole WS-Federation Passive.
  • Aucun Relying Party ne doit crypter son jeton.
  • Octopus offre un service de Metadata permettant de faciliter la configuration de vos Relying Party.

Configuration des Relying Party

ATTENTION :

L'utilisation de multiples facteurs d'authentification, de restrictions d'autorisations, de modifications des règles de revendications et d'agrégation de plusieurs sources d'identité dépasse la portée de cette procédure. Référez-vous à votre spécialiste en fédération d'identité pour en savoir plus.

Pour configurer un Relying Party de manière minimale, utiliser la procédure suivante :

  1. Obtenir l’URL de metadata propre à votre environnement en allant dans Outils > Configuration de fédération d’identité et en cliquant sur le bouton de copie à la fin de la ligne. L'URL aura le format https://environnement.octopus-itsm.com/api. Bien que cette URL ne soit pas accessible directement, votre serveur pourra s'en servir pour obtenir l'information pertinente.
  2. Dans votre serveur ADFS, ajouter une nouvelle relation de confiance.
  3. Dans l’étape de choix de la source de données, copier l’URL obtenue à la première étape, puis faire Suivant.
  4. Dans l’étape du nom affiché, choisissez un nom descriptif (par exemple https://nom_client.octopus-itsm.com), puis faire Suivant.
  5. Dans l’étape de l’authentification multifacteur, choisissez de sauter l’authentification multifacteur, puis faire suivant.
  6. Dans l’étape d’autorisation, choisissez de permettre tous les utilisateurs, puis faire suivant.
  7. Dans l’étape de révision, confirmez que le Relying Party ne contient qu’un seul identifiant, que le cryptage n’est pas configuré, que les claims sont bien présents (Name, Given Name, Surname, E-mail Address), que le point de terminaison unique utilise le protocole WS-Federation Passive, puis terminer l’assistant.
  8. À partir du menu contextuel du Relying Party configuré, éditer les règles de Claims pour ajouter une règle.
  9. Choisir d’envoyer les Claims en utilisant une configuration personnalisée, et spécifier la règle suivante: 
    c:[
      Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname",
      Issuer == "AD AUTHORITY"
      ]
    => issue(
      store = "Active Directory",
      types = (
        "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name",
        "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress",
        "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/givenname",
        "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/surname"
        ),
      query = ";sAMAccountName,mail,givenName,sn;{0}",
      param = c.Value
    );

 

Configuration pour Azure AD

De manière générale, l'intégration d'Octopus avec Azure AD doit répondre aux critères suivants :

  • Vous devrez créer une application d'entreprise non publiée sur la galerie pour chaque environnement que vous souhaitez activer. La création de l'application d'entreprise est disponible sous le volet Azure Active Directory
  • Les utilisateurs devant accéder à l'application devront remplir les considérations suivantes:
    • Avoir une licence Azure AD Premium.
    • Être ajoutés comme utilisateur autorisé à l'application créée.
PRÉALABLES :

L’intégration d’Octopus avec Azure AD requiert que le champ Nom d’utilisateur Windows de vos comptes Octopus soit renseigné avec le Nom d’utilisateur principal (UPN) provenant d’Azure AD. C’est avec cette valeur que le système peut faire la correspondance entre un compte Octopus et un compte Azure AD. Pour ce faire, vous pouvez procéder via les approches suivantes :

  • ADSIReader
  • DataImporter
  • Saisie manuelle dans le champ Nom d’utilisateur Windows dans la fiche de vos utilisateurs. Sachez que ce champ peut contenir plus d’une valeur séparée par un point-virgule (;).

Configuration de l'authentification unique

Utiliser la procédure suivante pour configurer l'authentification intégrée, une fois l'application d'entreprise créée:

  1. Appuyer sur le bouton 2 - Configurer l'authentification unique.
  2. Choisir la méthode d'authentification SAML.
  3. Utiliser les informations ci-bas pour entrer la configuration SAML de base, puis enregistrer:​
    Identifiant [https://nom_client.octopus-itsm.com].
    URL de réponse [https://nom_client.octopus-itsm.com].
    URL de connexion [https://nom_client.octopus-itsm.com/web/login.aspx].​
    État de relais laisser vide.
    URL de déconnection laisser vide.
  4. Ajuster les revendications (claims) des utilisateurs selon les informations appropriées à votre environnement. Portez une attention particulière à la revendication name, qui est utilisée comme clé primaire pour identifier vos utilisateurs. Celle-ci doit contenir la même information que le champ Nom d'utilisateur Windows dans Octopus.
    ATTENTION :

    L’utilisation du mode d’authentification fédéré pour l’application Client Windows et les applications Batch (ex : MailIntegration) requiert que le champ Nom d’utilisateur Windows contienne le nom d’utilisateur principal (UPN). Sachez que ce champ peut contenir plus d’une valeur séparée par un point-virgule (;).

    • Si ce champ contient le nom de l'utilisateur seulement, alors il faut utiliser user.onpremisessamaccountname comme valeur pour la revendication name
      Voir en image

       
    • Si ce champ contient le nom d'utilisateur principal (UPN) de l'utilisateur (ressemblant à une adresse courriel), alors il faut utiliser user.userprincipalname comme valeur pour la revendication name
      Voir en image


  5. Prendre en note l'URL des métadonnées de fédération de l'application. Celle-ci a le format [https://login.microsoftonline.com/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/federationmetadata/2007-06/federationmetadata.xml?appid=yyyyyyyy-yyyy-yyyy-yyyy-yyyyyyyyyyyy] et est situé dans la section Certificat de signature SAML.
  6. À partir de la page principale de votre application d’entreprise, accéder à la section Authentification.
    Vous pouvez accéder celle-ci à partir de la section Propriétés via le lien vers l'inscription de l'application :
    « Si cette application réside dans votre locataire, vous pouvez gérer des propriétés supplémentaires sur l’inscription de l’application. »
    Accéder ensuite à la section Authentification.
  7. Ajouter la plateforme Applications de bureau et mobiles.
    URI de redirection https://login.microsoftonline.com/common/oauth2/nativeclient
    Voir en image

     

    Paramètres avancés → Autoriser les flux clients publics
    Activer les flux mobiles et de bureaux suivants → Oui​
    Voir en image

     

    Enregistrer les changements
  8. Accéder à la section API autorisées.
    Ajouter une autorisation
    • Microsoft Graph → Autorisations déléguées
    • openid → Consentement de l’administrateur requis → Non
    • Ajouter des autorisations

  9. Accéder à la section Autorisations dans votre application d’entreprise.
    Vous pouvez utiliser le raccourci disponible en bas de page :
    « Pour afficher et gérer les autorisations accordées pour des applications individuelles, ainsi que les paramètres de consentement de votre client, essayez Applications d’entreprise. »
    Appuyer sur le bouton Accorder un consentement d’administrateur pour [votre application]
    Voir en image

     
  10. Finalement, à partir de l’application Octopus, utiliser l’URL noté au point 5 pour effectuer la vérification de la compatibilité dans la fenêtre Configuration de fédération d’identité.
    AVERTISSEMENT :

    Le mode d’authentification avec Azure AD n’est pas disponible pour l’instant pour l’application Octopus Web (Octopus 5). Celle-ci serait inaccessible dans la mesure où le mode d’authentification avec Azure AD était activé. Nous sommes à compléter les travaux nécessaires et nous vous informerons lorsque vous serez en mesure de les utiliser.

Vérification de la compatibilité

Avant de lancer la vérification, il est important de fermer toutes les fenêtres de votre navigateur par défaut.

Une fois la vérification lancée, Octopus va tenter de valider la compatibilité de votre serveur d’authentification. La vérification aura le comportement suivant :

  • WinUI : aucun comportement apparent, cette tentative est faite en arrière-plan. Vous pourriez avoir à vous authentifier dans le contexte d’Azure AD.
  • Portail Web : le portail Web et l'application WebTech seront lancés dans une nouvelle fenêtre de navigation. Vous pourriez avoir à vous authentifier. Un message vous confirmera le fonctionnement.
  • Octopus Web : l’application Octopus 5 sera lancée dans une nouvelle fenêtre de navigation. Vous pourriez avoir à vous authentifier. Un message vous confirmera le fonctionnement.
Voir en image

Activation du mode d’authentification intégré pour les utilisateurs (Portail Web)

Lorsque vous êtes prêts à basculer le mode d’authentification des utilisateurs, sélectionner Identité fédérée dans la boite d’option appropriée et appuyer sur OK. Ce changement aura les impacts suivants :

  • Votre application va redémarrer.
  • Le changement du mode d’authentification s’applique aux utilisateurs de toutes les équipes. Assurez-vous d’avoir préalablement effectué des tests de fonctionnement pour ne pas laisser d’usagers sans accès.
  • Comme cette opération périme tous les jetons d’authentification actuels, les utilisateurs actuellement connectés au portail Web auront à se reconnecter.
  • À tout moment, revenez dans cette boîte d’option pour revenir au mode d’authentification préalable, dont les paramètres auront été conservés.

 

Activation du mode d’authentification intégré pour les intervenants (WinUI, WebTech, Octopus 5)

Lorsque vous êtes prêts à basculer le mode d’authentification des intervenants, vous n’avez qu’à sélectionner Identité fédérée dans la boîte d’option appropriée, et appuyer sur OK. Ce changement aura les impacts suivants :

  • Votre application va redémarrer.
  • Le changement du mode d’authentification s’applique aux intervenants de toutes les équipes ou interfaces. Assurez-vous d’avoir préalablement effectué des tests de fonctionnement pour ne pas laisser d’intervenant sans accès. Assurez-vous d’avoir préalablement effectué des tests de fonctionnement pour ne pas laisser d’intervenant sans accès.
  • Comme cette opération périme tous les jetons d’authentification actuels, les intervenants pourraient avoir à redémarrer leur application.
  • À tout moment, revenez dans cette boîte d’option pour revenir au mode d’authentification natif.


Tâches planifiées et outils d'intégration

Des considérations particulières doivent être données aux comptes exécutant les outils d'administration:

  • Les outils d'intégration (MailIntegration, ADSI, etc.) vont présenter au fédérateur d’identité la même identité que celle utilisée pour lancer la tâche planifiée.

    Vous devez donc vous assurer que les tâches planifiées dans Windows correspondent à des comptes valides dans ADFS / Azure AD.

     
    AVERTISSEMENT :

    Assurez-vous de ne pas activer l'utilisation de multiples facteurs d'authentification (MFA) pour les comptes exécutant les outils d'administration lorsque ceux-ci sont utilisés dans le cadre d'une tâche planifiée dans Windows.

  • Le fédérateur d’identité va ensuite présenter à Octopus cette même identité, c'est donc celle-ci qui doit au minimum correspondre à un utilisateur Octopus ayant une licence de traitement par lot et un rôle associé.
  • Lors de l'activation de l’identité fédérée, les commutateurs /Login et /Password des commandes deviendront superflues. Le commutateur /Team doit cependant demeurer.
    • Conserver les deux paramètres superflus: vous recevrez des avertissements que vous pouvez ignorer. En cas de retour arrière, les tâches vont continuer de fonctionner.
    • Retirer les deux paramètres superflus: vous ne recevrez plus d'avertissement. En cas de retour arrière, les tâches vont cesser de fonctionner.
      AVERTISSEMENT :

      Dans le contexte d’Azure AD, il est recommandé de spécifier le commutateur /Login. Windows met en cache les différents comptes Azure avec lesquels des utilisateurs se sont authentifiés sur le poste de travail. Pour éviter tout conflit, la présence du commutateur /Login assurera l’utilisation du compte utilisateur approprié.

 

Questions fréquentes relatives à la mise en place de la fédération d'identité

Si mon service d'identité fédérée n’est pas disponible, comment puis-je me connecter à Octopus ?
Dans le cas d'une panne de fédération d'identité, Octopus ne possède pas l'expertise nécessaire pour offrir le support pour le dépannage. 

En cas de panne de votre service de fédération: guide de dépannage

  • Aucun utilisateur ne pourra accéder aux différentes applications tant que le fédérateur ne sera pas disponible.
  • Seuls les intervenants aptes à modifier les paramètres d’authentification pourront se connecter. Pour avoir accès à l’application, ils devront maintenir la touche Majuscule enfoncée pour se faire proposer l’authentification par nom d’utilisateur/mot de passe. Ils pourront ensuite désactiver temporairement la fédération pour revenir au mode précédent.

Au besoin, nous allons aussi modifier le mot de passe d'un des administrateurs pour lui permettre l'accès, dans le cas où il ait oublié son mot de passe.

Comment puis-je activer OAuthClient sur mon serveur ADFS?

À partir d’une invite de commande « Powershell », taper la commande suivante en remplaçant "monsite" par tous les noms qui peuvent être invoqués par vos environnements : 

Add-AdfsClient -Name "octopus-itsm.com" -ClientId "octopus-itsm.com" -RedirectUri @("https://monsite.octopus-itsm.com/", "https://monsite.octopus-itsm.com/octopus/", "https://app.octopus-itsm.com/monsite/", "https://app.octopus-itsm.com/monsite/octopus/", "https://app1.octopus-itsm.com/monsite/", "https://app1.octopus-itsm.com/monsite/octopus/", "https://app2.octopus-itsm.com/monsite/", "https://app2.octopus-itsm.com/monsite/octopus/", "https://app3.octopus-itsm.com/monsite/", "https://app3.octopus-itsm.com/monsite/octopus/" )

Enable-AdfsEndpoint -TargetAddress "/adfs/oauth2/"
  • Votre nom de site doit être complètement en minuscule.
  • Il faut inclure la barre oblique (slash) finale dans toutes les RedirectURI.

Certaines versions du serveur ADFS nécessitent que la permission soit octroyée en utilisant la commande suivante, en remplacant correctement l'URL de votre Relying Party:

Grant-AdfsApplicationPermission -ClientRoleIdentifier "octopus-itsm.com" -ServerRoleIdentifier "https://monsite.octopus-itsm.com/"

Octopus peut-il fonctionner avec d’autres fournisseurs d'authentification supportant la norme WS-Federation ?

Bien que théoriquement d’autres fournisseurs conformes à la norme pourraient fonctionner, aucun d’entre eux n’a été testé. Actuellement, la combinaison de produit testée et fonctionnelle est de faire fonctionner Octopus avec un ADFS 3.0 / 4.0 derrière un ADFS 3.0 / 4.0 Proxy ou un Azure AD.

Si vous hébergez un système différent conforme, mais non supporté, vous pouvez tout de même tenter de faire fonctionner l’authentification unique en nous fournissant les informations requises citées plus haut.

Comment faire fonctionner l'authentification automatique pour Chrome et Firefox?

Par défaut, ADFS 3.0 / 4.0 ne permet pas l'authentification automatique kerberos/NTLM pour certains navigateurs. Ceci fait que même si l'utilisateur est à l'interne il est redirigé à la page de connexion ADFS plutôt que de profiter de l'authentification automatique.

Voici quelques liens utiles pour comprendre et résoudre ce problème: 

Comment puis-je dépanner l’authentification unique lorsque celle-ci ne fonctionne pas ?

De la même manière que la plupart des autres services sécurisés que vous offrez sur Internet :

  • Du point de vue global, assurez-vous que le nom DNS résolve correctement votre serveur mandataire.
  • Assurez-vous que votre pare-feu autorise les communications sécurisées vers votre serveur mandataire.
  • Assurez-vous que votre serveur mandataire reçoive bien les tentatives de connexion provenant de vos clients.
  • Assurez-vous que le service ADFS fonctionne correctement sur votre serveur mandataire.

Quelle icône puis-je utiliser pour publier Octopus sur le portail Office 365 ?

Utilisez l'icône suivante pour publier Octopus sur votre portail Office 365.

Voir en image

Mon équipe n’a pas d’expertise pour déployer le service de fédération, pouvez-vous nous proposer un fournisseur pouvant nous accompagner dans la démarche ?

Malheureusement, Octopus n’est pas actuellement en mesure de recommander un fournisseur de service en particulier.

X
Aidez-nous à améliorer l’article








Aidez-nous à améliorer l’article