Nous voulons préparer le/la responsable à ce qui l'attend
Dès l'étude de projet et la conception d'une nouvelle solution informatique, il est très important de se pencher de manière approfondie sur le thème de la gestion des identités et des autorisations. Pour ce faire, le projet établit généralement un concept d'utilisateurs et d'autorisations (concept IAM). Ce concept aborde une multitude de questions telles que:
Qui sont les utilisateurs de mon application et dans quels rôles l'utilisent-ils?
Sont-ils des collaborateurs (internes/externes) de l'administration fédérale? De ma propre unité administrative ou d'autres unités administratives dans le contexte de l'entreprise?
Sont-ils des collaborateurs d'administrations cantonales dans le contexte G2G?
Sont-ils des partenaires dans le contexte G2B?
Sont-ils des citoyens dans le contexte G2C?
Comment les informations sur les identités et les données de base des utilisateurs sont-elles utilisées dans mon application ? Mon application doit-elle disposer d'informations sur les utilisateurs uniquement au moment où ces derniers utilisent le système ou également en dehors de celui-ci?
Les données de base des utilisateurs doivent-elles être mises à jour dans mon application lorsque, par exemple, le nom d'un utilisateur change et comment cela se fait-il?
Comment la gestion des identités et des autorisations est-elle organisée? Par une organisation centralisée au plus près de l'application ou décentralisée au plus près de l'utilisateur et de son organisation?
Comment se présente le cycle de vie des identités, de leurs données de base et de leurs autorisations pour les différents groupes d'utilisateurs de mon système?
Est-ce que chaque utilisateur intéressé doit pouvoir utiliser l'application (service public) ou est-ce que l'application n'est disponible que pour les utilisateurs qui remplissent des conditions spéciales?
Doit-on permettre à un utilisateur de demander l'accès à l'application de sa propre initiative ? Comment se présente le processus de demande, de vérification, d'autorisation et d'attribution des droits?
Est-ce qu'il y a déjà une base d'utilisateurs existants qui vont utiliser mon application et qu'une migration doit donc avoir lieu?
Quelle est la complexité de la structure des autorisations?
Comment évaluer le besoin de protection des données dans mon application en termes de confidentialité et de protection des données?
Où le système doit-il être exploité (sur site, dans un cloud)?
Dans quelle zone du réseau mon application doit-elle être exploitée pour que les exigences de protection soient satisfaites?
Comment puis-je m'assurer, dans le cas d'une zone à besoin de protection élevé, que les accès autorisés peuvent être effectués dans cette zone, mais que les utilisateurs non autorisés n'ont pas accès à la zone?
Les utilisateurs accèdent à l'application dans leur propre intérêt personnel ou en tant que représentant d'une organisation et ce représentant peut changer à tout moment?
et bien d'autres sujets encore...
Identités dans eIAM
Une identité d'authentification pointe exactement sur une identité composite (1:1).
Une identité composite pointe exactement sur une référence d'identité dans un mandant Access (1:1).
Une identité composite peut pointer sur des références d'identité dans 0-n mandants d'accès (0:n).
Une référence d'identité peut avoir 0-n profils par mandant Access (0:n).
Un profil peut avoir 0-n rôles assignés (0:n).
Grâce à l'intégration avec eIAM
L'intégration de votre application avec le service eIAM de l'IKT-SD IAM V2 de l'administration fédérale vous soulage en tant que responsable à bien des égards.
Les utilisateurs peuvent utiliser leurs identités électroniques existantes et leurs moyens de preuve d'identité pour accéder à votre application.
Votre application peut profiter des processus existants, sûrs et confortables pour l'utilisateur, pour la création et la gestion de son identité électronique. Elle n'a pas besoin de les implémenter elle-même.
Votre application peut authentifier les utilisateurs de manière sûre via des jetons standardisés émis par eIAM pour reconnaître l'identité du sujet accédant. Elle ne doit pas implémenter elle-même une multitude de procédures d'authentification complexes.
Votre organisation peut-elle utiliser les processus existants pour l'intégration des identités électroniques dans son application?
Votre organisation peut utiliser l'infrastructure IAM existante, hautement disponible et gérée de manière professionnelle, pour la gestion des utilisateurs et de leurs autorisations.
Un point d'application de la politique de proxy inverse (RP-PEP) d'eIAM peut permettre un accès conforme à la politique à votre application, si la politique de la zone l'exige (par exemple, si l'application doit être exploitée dans une zone SZ+ pour un besoin de protection accru).
