Première utilisation de l'application pour les nouveaux utilisateurs

Dans le cadre de la demande d'accès, un utilisateur peut demander l'accès à une application métier pour une identité dédiée. Si cette identité n'existe pas encore dans le mandant d'accès correspondant, cette identité y est créée et référencée à l'identité dans l'FI correspondant. Dans le cadre de la demande d'accès, les rôles nécessaires à son travail dans l'application sont attribués à l'identité.

Variantes de la demande d'accès:

  1. Demande d'accès automatisée sans interaction (mode silencieux).
    Dans le meilleur des cas, vous ne remarquez même pas la demande d'accès. C'est le cas lorsque les rôles de l'application sont attribués automatiquement et que le setup est configuré de manière à ce que le "mode silencieux" soit appliqué. Ainsi, les rôles sont attribués en arrière-plan, juste à temps, sans interaction avec vous. → UseCase: aucune autorisation n'est prévue pour l'accès au domaine public de l'application. 
    Le contrôle de l'accès aux applications s'effectue par le biais des rôles de granularité grossière ou fine. Si aucun rôle n'est défini dans l'application, le rôle grossièrement granulaire "ALLOW" est saisi pour l'accès à l'application.
    Le contrôle de l'accès aux applications s'effectue par le biais des rôles de granularité grossière ou fine. Si aucun rôle n'est défini dans l'application, le rôle grossièrement granulaire "ALLOW" est saisi pour l'accès à l'application.

  2. Demande d'accès suivie d'un processus de validation (Utilisateur demande d'accès -> BVA).
    Dans le cas d'une demande d'accès suivie d'un processus de validation, les rôles ne sont pas attribués automatiquement. La demande est envoyée à un responsable des autorisations, qui soit dispose déjà des informations nécessaires à l'attribution des autorisations, soit procède aux vérifications nécessaires et prend éventuellement contact avec le demandeur. → UseCase: Le premier accès à l'application est libéré via le processus d'autorisation. 
    L'accès à l'application doit se faire par le biais d'une demande d'accès de l'utilisateur au BVA (gestionnaire des utilisateurs de l'application) compétent.
    L'accès à l'application doit se faire par le biais d'une demande d'accès de l'utilisateur au BVA (gestionnaire des utilisateurs de l'application) compétent.

    Rôles IDM & attributions d'accès

  3. Invitation centralisée sous la responsabilité du métier (BVA -> Code Onboarding pour l'utilisateur).
    Après la saisie centrale par un BVA, un code à usage unique (appelé onboarding-code) est envoyé à l'utilisateur automatiquement via eIAM par e-mail ou manuellement via un autre canal d'envoi. Login (ou auto-enregistrement s'il n'existe pas encore d'identité électronique) suivi de la saisie du code-onboarding; il en résulte la disponibilité immédiate de l'application cible. Les invitations sont générées par la gestion déléguée. → UseCase: Des utilisateurs ciblés peuvent être autorisés à l'avance et invités via un lien d'onboarding. Des autorisations individuelles peuvent ainsi être définies par utilisateur.
    4. Gestion déléguée

    La réinitialisation de l'onboarding, pour les utilisateurs déjà onboardés, peut également être effectuée par le portail Admin.

    Image du portail eIAM Gestion déléguée avec sélection des utilisateurs et sélection de la fonction Reset Onboarding.
    Feature: reset onboarding


  4. Invitation décentralisée sous la responsabilité d'unités organisationnelles, d'entreprises en dehors du métier.
    Avec la gestion déléguée, il s'agit en principe que ce ne soit pas le responsable des autorisations d'un office qui attribue des autorisations BVA, mais quelqu'un d'autre (voir à ce sujet la prestation 6 d'eIAM et la eIAM-Video à la minute 11). Les possibilités d'onboarding suivantes sont à votre disposition :
    • Code d'onboarding : eIAM envoie à la personne invitée un e-mail contenant un texte d'invitation et un code d'onboarding. La personne invitée utilise une seule fois le code d'embarquement en utilisant une identité électronique adéquate de son choix, cette identité électronique est ainsi reliée à l'application cible via eIAM.
    • People Picker: Avec People Picker, les identités eIAM déjà existantes peuvent être recherchées dans le contexte de l'entreprise, directement intégrées dans le mandant d'accès et ensuite autorisées par le manager délégué. Sans qu'un processus d'invitation ne soit nécessaire pour cela.
    • Bulk-Onboarding: Possibilité d'onboarding en masse des utilisateurs, y compris l'attribution de rôles IDM DelegAdmin pour la gestion des permissions, des unités et des utilisateurs.
    • Strict-Onboarding: Si l'onboarding strict est configuré dans les "Portal Properties" du Mandant d'accès, l'utilisateur DOIT saisir un numéro de téléphone mobile lors de l'onboarding.

    Gestion déléguée

  5. Invitation déclenchée automatiquement par le processus dans l'application métier via l'interface eIAM-RDM
    eIAM-RDM permet d'inviter des utilisateurs dans eIAM au moyen d'une API REST (Representational State Transfer). RDM est l'abréviation de Remote Delegated Management. La gestion déléguée consiste en principe à ce que ce ne soit pas le responsable des autorisations d'un office qui attribue les autorisations BVA, mais quelqu'un d'autre (voir à ce sujet la prestation 6 d'eIAM et la video eIAM eIAM-Video à la minute 11). En cas d'utilisation du RDM, ce n'est pas une personne qui déclenche l'invitation dans eIAM, mais une machine (processus dans l'application métier). eIAM envoie à la personne invitée un e-mail contenant un texte d'invitation et un code d'onboarding. La personne invitée valide une seule fois le code-onboarding en utilisant une identité électronique adéquate de son choix, cette identité électronique est ainsi reliée à l'application cible via eIAM.
    L'accès à l'application se fait par l'envoi automatisé d'un mail avec un code unique d'onboarding à l'utilisateur.
    L'accès à l'application se fait par l'envoi automatisé d'un mail avec un code unique d'onboarding à l'utilisateur.

    API eIAM-RDM

  6. Autoprovisioning
    L' Autoprovisioning permet, comme "mode silencieux" (Point 1), un login seamless pour l'utilisateur dans l'application, c'est-à-dire sans Access Request. L'avantage de cette méthode prestaging est qu'un groupe cible d'utilisateurs peut être créé à l'avance dans Access Client et doté des rôles nécessaires. Il n'y a pas d'attribution incontrôlable des autorisations pour une application, mais les autorisations sont mises à disposition et mises à jour pour le groupe cible défini, et ce sans Access Request pendant la connexion ! Le groupe d'utilisateurs qui obtient l'accès et les droits peut ainsi être défini à l'avance. → UseCase: Tous les collaborateurs obtiennent un accès en lecture dans l'application X ou tous les collaborateurs du département X - Auto provisioning créera les comptes et attribuera les rôles.

    Autoprovisioning

  7. Combinaisons des variantes ci-dessus 1&2 ou 3/4/5/6
    Les différentes procédures pour les autorisations peuvent être combinées à volonté. La condition est une délimitation claire en groupes d'utilisateurs, afin d'éviter tout chevauchement des procédures pour les utilisateurs. Par exemple, un compte doit être créé automatiquement pour les collaborateurs dans Access Client X et des rôles doivent leur être attribués. Pour les autres utilisateurs qui utilisent par exemple CH-LOGIN, une Access Request avec processus de confirmation doit être déclenchée. Au lieu de la demande d'accès, on peut aussi utiliser le processus d'onboarding en combinaison. D'autres possibilités sont envisageables, à savoir que les groupes d'utilisateurs et leur délimitation doivent être clairs, tout comme les processus souhaités pour l'autorisation. Si ces points sont clairs, une combinaison optimale d'accès et de mise à disposition des autorisations nécessaires peut être configurée. L'équipe de conseil se fera un plaisir de vous conseiller.

  8. Authentication Only
    Comme son nom l'indique, le pattern "Authentication Only" consiste en l'obtention d'informations d'identité et d'authentification pures par l'application. Avec "Authentication Only", l'application renonce à toute forme d'autorisation et de gestion des identités dans eIAM. Ceci parce que l'application n'a pas besoin d'autorisation ou qu'elle règle elle-même l'autorisation (en-dehors de l'eIAM).

    Ce modèle est idéal pour les intégrations qui ne nécessitent qu'une authentification par eIAM, mais pas d'autorisation globale ni de gestion des identités dans un mandant d'accès eIAM.

    Après l'authentification réussie du sujet accédant, eIAM fournit comme identifiant persistant l'identité eIAM fédérée du sujet dans le jeton. Ceci contrairement aux intégrations avec prestation d'autorisation, où l'identifiant persistant utilisé est le userExtId de la référence d'identité dans le mandant d'accès. Cette différence doit être prise en compte dans le cas où des applications devraient échanger entre elles des données sur le sujet. Dans ce cas, le pattern "Authentication Only" ne doit pas être utilisé en raison des différents identifiants.

    Avec cette forme d'intégration, seul le service d'authentification est proposé.
    Avec cette forme d'intégration, seul le service d'authentification est proposé.

    Le modèle d'intégration "Authentication Only" est disponible pour les identités électroniques des fournisseurs d'identités (FI) suivantes :
    • CH-LOGIN (y compris le bundle BYOI)
    • FED-LOGIN