Orchestrer la modernisation de l'identité à l'aide d' IBM Security Verify

Introduction

Une organisation doit gérer et transformer ses identités et ses référentiels d'utilisateurs. Les identités peuvent se trouver dans un référentiel d'utilisateurs sur site ou dans le nuage.

Voici les deux principaux cas d'utilisation :

1. La migration des identités sur site vers IBM Security Verify 's Cloud Directory permet aux organisations d'entamer leur voyage dans le nuage et de s'épargner les efforts de maintenance matérielle et les compétences nécessaires pour certains référentiels d'utilisateurs tels que LDAP ou AD.

2. Migrer le référentiel des utilisateurs vers un autre fournisseur, par exemple Ping Identity ou Okta.

L'article présente les étapes de configuration nécessaires pour migrer les utilisateurs de LDAP ou AD vers IBM Security Verify et pour migrer les utilisateurs LDAP ou AD vers un fournisseur d'identité 3rd.

Migration des utilisateurs de LDAP/AD vers IBM Security Verify

La gestion d'un référentiel d'utilisateurs nécessite du temps et des compétences pour assurer une maintenance et une assistance continues.
Les organisations ont besoin d'une solution pour réduire les coûts internes liés à la gestion du référentiel et se concentrer sur l'aspect commercial de leurs applications.

IBM Security Verify dispose de son propre référentiel d'utilisateurs, appelé Cloud Directory, qui offre une voie de migration transparente pour déplacer les utilisateurs d'un annuaire sur site vers Cloud Directory.

Prérequis

1. IBM Security Verify tenant
2. LDAP sur site, qui est le référentiel actuel des utilisateurs

Configuration du côté d' IBM Security Verify:

1. Se connecter à la console d'administration

2. Allez dans Intégrations > Agents d'identité.

3. Sélectionnez Créer une configuration d'agent.

   

4. Sélectionnez Authentification comme objectif et sélectionnez la tuile LDAP.
   Cliquez sur Suivant.

   

5. Sous Paramètres de connexion, indiquez les détails de la connexion LDAP.

   

6. Sous Propriétés de l'utilisateur, entrez les attributs de l'utilisateur qui sont définis dans les propriétés de l'utilisateur et renvoyés lors d'une opération de vérification du mot de passe réussie.

   

7. Sous Mappage d'attributs, mappez les attributs du fournisseur d'identité aux attributs de Verify Cloud Directory.

   

8. Dans la section "Prochaines étapes", les actions suivantes doivent être entreprises.

   1. Sélectionnez View API credentials et utilisez l'icône de copie dans le presse-papiers pour copier et stocker l'ID du client et le secret du client.

   2. . Téléchargez l'agent Bridge à partir du IBM Container Repository (ICR). Reportez-vous à la section Installation et configuration de Verify Bridge sur Docker pour plus de détails.

9. La configuration est ajoutée aux agents d'identité et le fournisseur d'identité est répertorié dans l'onglet Authentification > Fournisseurs d'identité.

   

10. Nous allons maintenant activer la migration des utilisateurs pour le fournisseur d'identité nouvellement créé.

11. Dans la section Liaison d'identité, sélectionnez Activer la liaison d'identité pour ce fournisseur d'identité et sélectionnez un identifiant d'utilisateur unique dans la liste déroulante.

12. Activer l'option de provisionnement juste à temps.

13. Sous Just-in-time provisioning, cochez la case Provision password migration pour activer la migration des mots de passe des utilisateurs vers le Cloud Directory.

14. La configuration est maintenant terminée, les prochaines étapes sont le flux de connexion et la validation.

Connexion avec IBM SDS

Accédez à votre locataire ISV et choisissez l'option de connexion à l'aide d' IBM SDS. Fournir les détails concernant l'utilisateur qui sont présents dans la FDS.

Se connecter avec Cloud Directory

Accédez à votre locataire ISV et choisissez l'option de connexion à l'aide de Cloud Directory. Veillez à fournir les mêmes informations d'identification que celles que vous avez utilisées pour vous connecter à SDS. Essentiellement, l'utilisateur est maintenant migré vers Cloud Directory et il n'a plus besoin de changer son nom d'utilisateur ou son mot de passe.

Ceci conclut le premier cas d'utilisation de la migration des utilisateurs de LDAP vers IBM Security Verify 's Cloud Directory.

Migration des utilisateurs de LDAP/AD vers un fournisseur d'identité tiers

Examinons maintenant le deuxième cas d'utilisation, à savoir la migration d'utilisateurs de LDAP ou AD vers un fournisseur d'identité tiers. Dans le cas d'utilisation décrit, Okta est le fournisseur tiers, mais il peut s'agir de Ping ou d' Azure.

Prérequis

1. IBM Security Verify tenant
2. Le concepteur de flux est activé dans votre locataire
3. Contenu d' IBM Security Verify SaaS Resources téléchargé ou cloné sur votre machine. Reportez-vous à la page des parents pour plus de détails sur la manière d'y parvenir. Le dossier est désigné ci-après par le terme $GIT_REPO.
4. LDAP ou AD sur site, qui est le référentiel d'utilisateurs actuel
5. Locataire Okta

L'utilisation de la fonction Setup - permet d'obtenir les résultats suivants

1. Utiliser Identity orchestrator comme mécanisme pour migrer les utilisateurs qui existent dans le registre des utilisateurs sur site.
2. Migrer les utilisateurs avec une partie de l'expérience de connexion.
3. Après la migration, les utilisateurs sont dirigés vers l'expérience d'authentification moderne.
4. Enfin, il faut éliminer le référentiel des utilisateurs sur site.

Vue d'ensemble du flux :

Configuration du côté d'Okta :

1. Générer un jeton pour que l'API puisse être exécutée sur votre locataire. Après vous être connecté, dans le menu de gauche, allez à Security-> API -> Create Token.

   

2. Configurez une application Web App pour établir une fédération entre Okta et IBM Security Verify.

   

3. Connectez-vous à la console d'administration -> Application (dans le menu de gauche)-> Application -> Créer une intégration d'application -> OIDC

4. Choisissez le type de subvention que vous souhaitez configurer - par défaut, le type de subvention Code d'autorisation est configuré.

5. Fournir des URI de redirection de connexion. Les valeurs proviennent d' IBM Security Verify. Par exemple, https://<your_verify_tenant>/auth/redirect.

6. Saisissez l'identifiant et le secret du client, ils sont nécessaires au moment de la configuration dans IBM Security Verify

Étapes de configuration du côté d' IBM Security Verify:

Pour permettre à IBM Security Verify de s'authentifier auprès de LDAP ou AD sur site, voici la marche à suivre

Active Directory comme source d'identité

https://www.ibm.com/docs/en/security-verify?topic=providers-configuring-prem-ldap-provider

Okta doit être ajouté en tant que fournisseur d'identité à IBM Security Verify

Chemin de configuration - Se connecter à la console d'administration -> Authentification -> Fournisseur d'identité -> Ajouter un fournisseur d'identité -> OIDC Enterprise.

Fournir le point de terminaison okta OIDC bien connu. Par exemple, https://<yourtenant>-admin.okta.com/.well-known/openid-configuration.

Définir le domaine et l'émetteur de la source d'identité nouvellement configurée. Le nom du locataire lui-même peut également être utilisé. Par exemple https://<yourtenant>-admin.okta.com.

Créer un attribut personnalisé et lui attribuer une règle

Un indicateur est maintenant nécessaire pour stocker la valeur indiquant si l'utilisateur est migré ou non. Le drapeau peut être qualifié de Migrated to Okta.

Créer un attribut de profil personnalisé - Dans le menu de gauche, cliquez sur Répertoire > Attributs > Attribut personnalisé.

La capture d'écran suivante montre l'aspect après l'enregistrement.

Pour attacher une règle, dans le menu de gauche, allez à Authentification -> Fournisseur d'identité -> Paramètres globaux -> Mappage d'attributs.

Copiez le script suivant et utilisez-le avec l'attribut personnalisé (migré vers Okta). La règle personnalisée consiste à créer l'utilisateur (juste à temps) avec le flux de connexion et à l'associer à un attribut personnalisé (migré vers Okta). De cette manière, il est possible de savoir quand l'utilisateur se connectera la prochaine fois et quelle expérience de connexion doit être proposée.

statements:
- context: >
    oktaTenant := "https://<your-tenant>-admin.okta.com"
- if:
    match: idsuser.getValue("JIT_realmName") != "<this is your On prem LDAP identity source realm name>"
    return: "false"
- context: >
    oktaToken := "<token>"
- context: >
    r := hc.Post(context.oktaTenant + "/api/v1/users", {
        "Accept": "application/json",
        "Content-Type": "application/json",
        "Authorization": "SSWS " + context.oktaToken
    }, jsonToString({
        "profile": {
            "firstName": idsuser.getValue("givenName"),
            "lastName": idsuser.getValue("sn"),
            "email": idsuser.getValue("mail"),
            "login": idsuser.getValue("mail")
        },
        "credentials": {
            "password" : { "value": idsuser.getValue("password") }
        }
    }))
- return: >
  context.r.responseBody.status == "ACTIVE" ? "true" : (context.r.responseBody.status)

Voici à quoi cela ressemble -

Thème de marque personnalisé

Ce flux présente des pages personnalisées et un thème doit donc être créé pour éviter d'affecter les flux utilisant le thème par défaut. Il existe deux fichiers personnalisés :

• custom_page1.html: Cette page demande le nom d'utilisateur.
• custom_page2.html: Cette page affiche une erreur en cas d'échec du flux.

Connectez-vous à la console d'administration IBM Security Verify et suivez les étapes indiquées.

1. Dans le menu de gauche, sélectionnez Expérience utilisateur et cliquez sur Image de marque

2. Créez un nouveau thème de marque intitulé "Migration LDAP to Okta". Vous pouvez suivre les étapes mentionnées ici.

   

3. Cliquez sur la tuile du thème pour afficher l'arborescence des fichiers.

4. Développez "workflow" > "pages" et cliquez sur les trois points verticaux à côté de custom_page1.html ". Cliquez sur "Télécharger".

   

5. Choisissez $GIT_REPO/flows/ldap_to_okta_migration/pages/templates/workflow/default/custom_page1.html " dans le dossier local. Cliquez ensuite sur "Télécharger".

   

6. Comme à l'étape précédente, sous "workflow" > "pages", cliquez sur les trois points verticaux à côté de custom_page2.html ". Cliquez sur "Télécharger".

7. Choisissez $GIT_REPO/flows/ldap_to_okta_migration/pages/templates/workflow/default/custom_page2.html " dans le dossier local. Cliquez ensuite sur "Télécharger".

Importer le flux de travail

1. Dans le menu de gauche, sélectionnez Expérience utilisateur et cliquez sur Concepteur de flux.

2. Cliquez sur l'icône d'importation adjacente au bouton Créer un flux.

   

3. Entrez les détails et téléchargez le fichier situé à "$GIT_REPO/flows/ldap_to_okta_migration/ldap_to_okta_migration GIT_REPO/flows/ldap_to_okta_migration/ldap_to_okta_migration.bpmn ". Cliquez sur Importer le flux.

   

4. L'écran du concepteur s'ouvre.

   

5. Sélectionnez la tâche "Set Vars" et modifiez les valeurs "okta_tenant" et "onprem_realm", onprem_realm est le nom de domaine de votre source d'identité LDAP ou AD.

   

6. Sélectionnez la tâche "Demander le nom d'utilisateur" et définissez le thème sur "Migration LDAP vers Okta".

   

7. Cliquez sur Enregistrer les modifications et Publier.

Le flux d'eau est en marche

1. Dans l'onglet "Paramètres" du flux, copiez l'" URL exécution".

   

2. Ouvrez un onglet incognito ou un navigateur complètement différent et collez l' URL.

3. Saisissez le nom d'utilisateur et cliquez sur "Continuer".

4. L'utilisateur est redirigé vers la source d'identité LDAP sur site.

5. Déconnectez-vous et collez à nouveau l' URL. Cette fois, l'utilisateur est redirigé vers la connexion à l'aide d'okta.

L'enveloppe

Ces flux sont une combinaison de plusieurs capacités puissantes fournies par IBM Security Verify

1. Utilisation du concepteur de flux pour orchestrer un flux de migration complexe
2. Fonctions permettant d'écrire des scripts logiques complexes
3. Prise en charge prête à l'emploi des sources d'identité de l'OIDC Enterprise
4. Migration prête à l'emploi des utilisateurs et des informations d'identification de LDAP vers Cloud Directory

💎

Vivek Jain, IBM Security