J'ai eu l'occasion ces derniers temps de travailler sur les deux produits phares de Sailpoint : Identity IQ (IIQ), la version "on premise" et IdentityNow (IDN), la version SaaS = Software As A Service.

L'éditeur semble mettre en avant la solution SaaS, mais même si celle-ci évolue rapidement (sans doute beaucoup plus vite que IdentityIQ), il y a encore quelques limitations.

Cet article - rédigé début janvier 2022 - est un constat, suite à la mise en place réalisée dans un contexte client spécifique. Dans la conclusion, je tente de dresser le "portrait robot" d'un environnement client qui serait bien adapté au déploiement de la version SaaS.

L'article est en cours de rédaction et sera enrichi au fur et à mesure.

Architecture

IdentityIQ

L'application IdentityIQ est écrite en java, et nécessite donc :

• un serveur d'application Java pour s'exécuter (Apache Tomcat, Oracle WebLogic, IBM WebSphere, JBoss EAP). Les plates-formes supportées sont assez vastes : Windows, Linux, IBM AIX, Solaris. Les serveurs peuvent être exécutés chez des cloud provider (AWS ou autre)
• Les données sont stockées dans une base de données. SailPoint supporte ainsi Oracle, SQL Server, MySQL, IDM DB2, ainsi que des instances AWS RDS (Oracle, MySQL, MS SQL, Aurora).
• Si on veut provisionner des comptes sur un Active Directory, il faut également installer un composant IQ Service, sur un serveur tournant sous Windows.

IdentityNow

Dans la version SaaS, SailPoint héberge les composants "cloud", correspondant au serveur d'applications et à la base de données.

Mais il faut quand même installer des composants dans le LAN du client :

• Un "connector server", fourni sous la forme d'une virtual appliance (VA), qui fait la passerelle entre les applications / sources du client et la plate-forme cloud
• Un composant IQ Service si on veut provisionner un Active Directory.

Actuellement (janvier 2022), même si l'ensemble de vos applications se trouve en mode SaaS, il faut quand même installer une VA, qui va communiquer avec vos applications.

A savoir que tous les échanges entre la virtual appliance et IDN se font à l'initiative de la VA. Seuls des flux sortants (https) sont nécessaire.

Identités

IdentityNow

IdentityNow permet de définir des profils d'identité différents, qui sont liés à une source autoritaire. Chaque profil peut avoir ses propres attributs (le modèle est extensible). Dès qu'un attribut est déclaré pour un profil, on peut également l'utiliser dans les autres profils.

Identity IQ

IdentityIQ ne définit, quant à lui, qu'un seul modèle d'identité. On peut éventuellement préciser un type en se basant sur un attribut. Le modèle est également extensible. Une partie des attributs sera stocké en tant que colonne dans la base de données (les attributs indexés, sur lesquels on peut faire des recherches) ; l'autre partie est stockée dans un "blob" XML.

Un attribut n'a pas forcément de source autoritaire directement liée (ceci permet de faire de la saisie manuelle).

Gestion des comptes

IDN : "Account profile" uniquement en création via les IHM. Tout le reste se fait via les API REST.

La suppression des comptes n'est pas supportée sur IdentityNow.

Pour être honnête, ce n'est pas non plus supporté de base dans IdentityIQ, mais on peut écrire des workflows qui vont supprimer les identités qui ne sont plus utilisées.

Saisie des informations

IDN est conçu pour utiliser des sources autoritaires pour les données : systèmes RH, fichiers, etc. En fait chaque profil d'identité est lié à une source autoritaire.

Il n'est pas possible de faire une saisie manuelle pour enrichir un profil utilisateur. Oubliez donc la saisie d'informations liées aux missions non connues des RH, ou les fonctions additionnelles dans le cas de postes à responsabilités multiples (potentiellement dans des lieux différents).

De même, le modèle de données pour la saisie manuelle est limité à 10 attributs spécifiques, et la personnalisation des écrans est très limitée sur IDN :
pas de listes de valeurs, pas de validation, etc.

Sur IIQ, on peut définir un modèle de données très riche, et (via le module LCM) avoir des écrans de saisie pour la création / modification des utilisateurs. On peut aussi définir des workflows qui auront leur propre écran de saisie, pour séparer les responsabilités.

Gestion de données de référentiels

IIQ propose de gérer certaines données de type référentiel, sous forme de "Managed Attributes". Ceux-ci peuvent être agrégés à partir de différentes sources, et sont utilisables par la suite dans les écrans de saisie, afin d'afficher des listes de valeurs. Ces données proviennent d'une ou plusieurs source(s) / application(s), et on peut donc s'appuyer sur des données existantes provenant de fichiers plats, bases de données ou annuaires LDAP.

IDN ne propose pas cette fonctionnalité, mais vu l'orientation "sans écrans", ceci peut s'expliquer.

Synchronisation Identité / compte

IDN : synchronisation à partir d'un attribut d'identité. Règles de transformation ? Seuls les attributs d'identité inclus dans le "Create Profile" peuvent être utilisés. On peut cependant définir quels attributs sont ensuite synchronisés, et éventuellement avoir des règles de transformation selon l'opération (create / update / delete).

IIQ : via les formulaires, règles, scripts, etc.

Gestion des droits internes

IDN : les demandes d'accès peuvent être paramétrées pour être faites par l'utilisateur lui-même, le manager ou n'importe qui dans l'organisation.

IIQ : la solution dispose de "capabilities", qui peuvent être basées sur des attributs / rôles afin de limiter les droits (ex : HelpDesk). On a une notion de périmètre (scope) dans IdentityIQ, que je n'ai pas retrouvé dans IdentityNow.

Gestion des accès

Dans IDN, il n'est pas possible de demander une suppression d'un droit, sauf dans le cas d'une recertification.

Dans IIQ, la gestion des rôles permet d'ajouter ou d'enlever des rôles, via les écrans, sans forcément passer par une phase de certification.

Déploiement des développements et paramétrages

Avec IDN, la plupart du paramétrage est déployé et mis à jour via des API. La configuration utilise le format json.

Avec IIQ, le paramétrage peut être fait via l'interface d'administration. On peut également exporter les objets en XML, qui peuvent alors être réimportés (via la console iiq) sur une nouvelle instance.

IIQ permet également de développer du code en BeanShell ou en Java, en profitant de la large gamme d'API proposées par le produit. Via les outils fournis par SailPoint,il est possible de customiser fortement la solution, et notamment de compiler les éléments de manière autonome.

Dans IDN, on peut écrire certaines règles en BeanShell, mais il est difficile de les tests / compiler en local, et leur déploiement (côté Cloud) doit toujours passer par l'intermédiaire (payant) de SailPoint. L'approche est donc bien moins souple.

Conclusion

Dans l'état actuel (janvier 2022), je ne recommanderai IdentityNow que dans certains cas assez précis :

• Tous les types d'utilisateurs sont gérés dans un système de type RH, de préférence disposant d'un connecteur SailPoint (par exemple Workday)
• Toutes les données servant à calculer des droits sont contenues dans ce système. Il ne faut pas imaginer enrichir le modèle d'identité via des saisies manuelles. On peut toutefois utiliser des API pour les sources de type "Non Employee", mais toujours avec la limite du nombre d'attributs spécifiques.
• Les règles de transformation d'attributs sont simples : pas de calcul de numéro de séquence ou de choses complexes
• On ne doit / veut pas gérer de données de références. Du coup, on peut avoir de multiples règles de transformation de type lookup qui "simulent" des données de référence, avec la lourdeur inhérente à ce mode de fonctionnement : maintenance manuelle des "transformations"
• On ne cherche pas à donner de l'autonomie pour enlever des droits
• Il n'existe pas de workflows complexes à implémenter (cette fonctionnalité devrait arriver en 2022)

Si vous avez par contre des besoins d'enrichissement manuel des informations de l'identité - par exemple parce que ces informations sont issues du terrain et ne sont pas connues ni gérées dans un système autoritaire - il vaut mieux s'orienter vers IdentityIQ, qui sera mieux à même de convenir.

IdentityIQ est plus riche fonctionnellement, et peut s'apparenter à une boîte à outils. On peut développer sa propre logique, soit en beanshell soit directement en java, en s'appuyant sur les nombreuses API du produit, qui sont bien documentées. L'une des principales différences lors du développement est que l'on peut avoir un accès aux informations d'identités ou de comptes un peu partout.

Dans tous les cas, il est vraiment nécessaire de passer par une phase de spécifications pour définir les besoins à couvrir, en rentrant dans le détail. Car certaines choses qui semblent couvertes par IdentityNow ne sont au final par encore disponibles ou pas faisables. La séparation nette entre les données d'identité (côté Cloud) et les données des comptes (côté Virtual Appliance) peut poser des soucis dans certains cas de figure.