Gestion des identités et accès clients : les fonctionnalités clés

Caractéristiques notables pour le CIAM

La première des caractéristiques importantes à garder à l'esprit lors de l’évaluation de produits de CIAM est l'adaptabilité. Par ce terme, on entend un certain nombre de choses. Tout d'abord, il se rapporte à différents scénarios d'interaction client à l'échelle ; c'est-à-dire à la façon dont les clients vont interagir avec les services et applications.

Cela recouvre des questions telles que l'authentification adaptative (demande de facteurs d’authentification supplémentaires selon le contexte), la collecte de signatures des terminaux, l'enregistrement des utilisateurs, la réinitialisation du mot de passe en libre-service, etc. Mais cela concerne également les caractéristiques spécifiques pour supporter les clients dès le départ, ainsi que la flexibilité nécessaire à la mise œuvre de ce qui est prévu à plus long terme.

On parle également de capacité d'adaptation pour faire référence aux informations de personnalisation et de souscription des utilisateurs. Par exemple, un système qui se concentre uniquement sur le stockage et la récupération des identifiants d'utilisateur, est à peu près ce que la plupart des organisations servant directement des clients ont déjà aujourd'hui. Gagner en sophistication, c'est s'assurer de l'extensibilité future.

Car il y a d'autres choses pertinentes au sujet des clients au-delà de leur identification. De quel niveau de service disposent-ils ? Comment aiment-ils recevoir de l'information ? Quelles sont leurs préférences en matière de confidentialité ? Quel thème graphique aiment-ils ? La solution de CIAM doit permettre le stockage, la récupération et la modification rapides de toutes ces informations, sans délai de réponse observable.

Une autre caractéristique importante est la capacité de fédération au sein du système d’information interne et d’interaction avec les fournisseurs d'identité externes. Un utilisateur à qui l'on présente un mode de connexion pratique via une plateforme de réseau social est beaucoup plus susceptible de s'inscrire qu'un utilisateur confronté à un formulaire de création de compte long et fastidieux. Mais l'intégration sociale n'est que la surface. L'autorisation est également transparente une fois qu'un client se trouve dans son environnement. Et c'est là que la prise en charge des normes établies du marché se traduit par une flexibilité accrue pour permettre une expérience sans couture. Par exemple, OAuth 2.0 permet de tirer profit de LinkedIn en tant que fournisseur d'identité (pour faciliter l'acquisition de clients), quand SAML permet de transférer la session client à son partenaire de service client par dialogue interactif en ligne.

Et bien sûr, il convient de ne pas oublier ses exigences actuelles et futures en matière de sécurité et de conformité. Encore une fois, c'est une question d'extensibilité. Par exemple, la reconnaissance des terminaux et l'authentification de base par mot de passe peuvent être considérées comme acceptables pour le libre-service aujourd'hui. Mais dans un avenir proche, l’authentification à facteurs multiples peut être déjà prévue pour offrir de futures possibilités de transferts de fonds. Au-delà, la possibilité de produire des rapports sur des éléments spécifiques, comme le RGPD, peut être tout aussi importante que celle, pour le client, de modifier ses données – pour, par exemple, renoncer à des programmes marketing.

Enfin, le support aux développeurs est un aspect essentiel du CIAM. Tous les systèmes CIAM interagissent étroitement avec les applications métiers ; il est donc essentiel que les développeurs puissent assurer une bonne intégration. En d'autres termes, la « convivialité » vis-à-vis des développeurs n’est pas un bonus dans un système de CIAM ; c'est aussi primordial pour la sécurité.

Considérations relatives à l'intégration

Ces facteurs sont importants lors de l’examen de l’offre du marché. Mais il y a encore du travail à faire pour jeter les bases du déploiement. Et là, il est essentiel de connaître et comprendre le déroulement prévu des interactions avec les clients, qui devra être supporté dès le départ.

Cela semble plus facile que cela ne l'est pour plusieurs raisons. Tout d'abord, historiquement, de nombreuses équipes de sécurité se concentraient largement sur la sécurité des réseaux et moins sur celle des applications. Celles qui sont dans ce cas ne comprennent pas ou n'examinent pas en profondeur les nuances du flux des applications, les cas d'utilisation, les retours des clients, ou encore les protocoles qui régissent les interactions des composants applicatifs.

Qui plus est, les cycles de développement deviennent de plus en plus rapides au fil du temps. Le mode agile a rendu les cycles de mise en production plus rapides qu'ils ne l'étaient ; DevOps a encore accéléré le mouvement. De même, des technologies telles que les conteneurs ou les fonctions en mode service contribuent au développement, mais peuvent rendre la compréhension du « substrat » plus délicate et plus longue. Idéalement, il convient de construire une compréhension de l’application dans une perspective de flux. Et si des artefacts de modélisation des menaces, comme des diagrammes de flux de données, sont déjà disponibles, il peut être utile de les utiliser dans cette phase.

Une fois que les flux actuels et futurs des applications, sont clairement maîtrisés, il convient de discuter avec les équipes de support et de service client, de la façon dont l'expérience utilisateur liée à l'identité du client (par exemple, gestion des comptes, profils, etc.) peut être optimisée. Vient ensuite la comparaison des caractéristiques des solutions de CIAM envisagées avec ces informations. Ainsi que celles remontées par les développeurs pour savoir où et comment ils peuvent intégrer la solution de CIAM dans les services qu'ils ont déjà créés.