inclusion etude des solutions libres de type IDM
This commit is contained in:
parent
74207b46e4
commit
c9d4acc871
309
doc.md
309
doc.md
|
|
@ -41,315 +41,6 @@ Plus facile à mettre en place que des solutions basées SAML ?
|
|||
## Approvisionnement
|
||||
|
||||
## Implémentations
|
||||
### Authentic 2
|
||||
écrit en Django
|
||||
TODO Installation et déploiement en local
|
||||
TODO Ecriture d'un dummy SP pour tester Authentic ??
|
||||
|
||||
TODO Expliquer les particularités de la licence GNU Affero GPL (APGL) :
|
||||
- l'utilisation du code pour des applications Web déployées est pris en compte dans le caractère transitif ("contaminant") de la licence.
|
||||
TODO Quel intérêt de licencier la documentation sous Creative Commons ?
|
||||
#### Documentation
|
||||
Comprendre l'interaction avec Lasso pour le support SAMLv2
|
||||
|
||||
One-time password support ?
|
||||
|
||||
Sphinx, génération de la doc
|
||||
Cf structure des fichiers rst
|
||||
|
||||
##### Administration
|
||||
L'administration d'Authentic 2 se fait de façon classique, à l'aide du module d'administration de Django, lequel propose une interface graphique disponible à la page `/admin/` du site.
|
||||
Il faudra cependant veiller à créer un *superuser* lors de l'initialisation de la base.
|
||||
|
||||
Le contrôle d'accès aux ressources Authentic se fait par recours à deux politiques globales appelées 'Default' et 'All'. //TODO reformuler
|
||||
Le mécanisme de politiques d'accès géré par Authentic est extensible : l'administrateur du service peut en définir, en plus des politiques 'Default' et ' All'.
|
||||
|
||||
Le niveau de granularité de ces politiques est l'objet : à chaque objet il est possible d'attribuer une politique d'accès. // Au sens de la POO ?
|
||||
|
||||
//TODO Pourquoi est-il nécessaire d'appliquer la politique 'All' sur tous les objets ? Quel(s) problème(s) si on ne le fait pas ?
|
||||
|
||||
##### Gestion des attributs SAML2
|
||||
Il s'agit ici de configurer une politique de gestion des attributs envoyés dans les réponses de succès d'authentification envoyées par Authentic 2 aux SPs.
|
||||
|
||||
L'utilisation des attributs SAML2 dans les réponses Authentic varie en fonction des cas d'utilisation, Authentic peut ou on être configuré en tant que SP SAML2.
|
||||
|
||||
//TODO Relire `attribute_management.rst`
|
||||
Ligne 207 : une associe une politique à un SP
|
||||
Cas particulier du SSO
|
||||
Revoir scenario d'utilisation avec mire de connexion
|
||||
|
||||
##### Authentification
|
||||
Avec LDAP ou laissée à PAM
|
||||
Rappel: la configuration de PAM sous UNIX se fait à l'aide des fichiers situés dans `/etc/pam.d`
|
||||
|
||||
Configuration de la variable `AUTHENTICATION_BACKEND` du `settings.py` des sources Django.
|
||||
|
||||
##### SAML2 et croisement des données entre différents compte
|
||||
Cette possibilité de croisement des données entres les différents comptes liéss à une même identité est au coeur de la fédération d'identité (On parle de *account linking consent*).
|
||||
|
||||
C'est le fournisseur d'identité (IdP) qui gère le consentement des utilisateurs à la liaison de leurs différents comptes.
|
||||
Les données ne sont pas forcément croisées, il peut simplement s'agir de la mise en place d'un mécanisme de SSO.
|
||||
|
||||
Dans ce cas, le message SAML AuthnRequest contient un champ indiquant le choix de l'utilisateur quant au croisement des ses comptes.
|
||||
|
||||
Si l'IdP manipule des identifiants opaques (*transient*), alors le consentement de l'utilisateur au croisement des comptes n'est pas nécessaire. //TODO à vérifier
|
||||
|
||||
On notera aussi que le fournisseur de service (SP) est en droit de refuser un SSO valide si le consentement de l'utilisateur n'a pas été recueilli. //S'agit-il ici de Authentic en tant que SP ?
|
||||
|
||||
Il faut aussi gérer le consentement à la redirection d'attributs (*attribute forwarding consent*).
|
||||
Dans Authentic 2, cette politique de gestion consiste en un choix parmi trois possibilités :
|
||||
* Ne pas demander à l'utilisateur son accord
|
||||
* Recueillir un consentement global pour l'ensemble des attributs ("Tout ou rien")
|
||||
* Permettre à l'utilisateur de choisir, attribut par attribut, ceux qui peuvent être redirigés
|
||||
|
||||
#### authentic2-ctl
|
||||
installation par pip en local
|
||||
pip install ./
|
||||
Outil d'administration en ligne de commande
|
||||
|
||||
#### Installation
|
||||
* AttributeError: 'module' object has no attribute 'PassThroughManager'
|
||||
quand : utilisation de authentic2-ctl
|
||||
pourquoi : incompatibilité sur les versions récentes du module django-model-utils
|
||||
solution : rétrograder le module django-model-utils à une version <= 2.3
|
||||
|
||||
##### virtualenv Python
|
||||
Le mécanisme de création d'environnements virtuels sous Python permet de faire cohabiter sur un même système des installations disparates. Par exemple, un même module Python peut être présent en différentes versions tant que ces versions se situent dans des environnements virtuels différents.
|
||||
|
||||
Les répertoires d'installation des modules Python dans le cadre d'un virtualenv sont seulement locaux à l'environnement créé.
|
||||
|
||||
##### Troubleshooting
|
||||
-
|
||||
|
||||
|
||||
##### Utilisation des *tenants* du SGBDR
|
||||
|
||||
### Apache Syncope
|
||||
Syncope est le projet d'outil de gestion des identités numériques de la fondation Apache.
|
||||
Il est écrit en J2E et est distribué sous licence Apache.
|
||||
|
||||
L'identité numérique consiste en un ensemble de demandes qu'un sujet numérique peut effectuer à propos de lui-même.
|
||||
|
||||
Notion de cycle de vie des données d'identité telle que définie par le projet, à travers le *provisioning* et le *deprovisioning*.
|
||||
|
||||
//TODO Inclure image du projet Apache Syncope
|
||||
|
||||
|
||||
#### Tuto officiel (*Getting Started*)
|
||||
La problématique centrale de GI telle que le conçoit Syncope est
|
||||
"Qui a accès à Quoi, Quand, Comment et Pourquoi ?"
|
||||
|
||||
Trois types d'objet sont définis par Apache Syncope : les utilisateurs (*Users*), les groupes (*Groups*), et d'autres objets n'appartenant pas à ces deux premières classes, par l'introduction des objets de type *Any*.
|
||||
|
||||
Plusieurs techno différentes sont nécessaires dans un scenario de gestion des identités avec Syncope.
|
||||
Comme la plupart des IdM, Syncope nécessite l'utilisation d'un outil de stockage des identités (*Identity Store*). Il peut s'agir d'un SGDBR, d'un annuaire LDAP ou même d'un fichier "à plat".
|
||||
Syncope prend en charge les fonctionnalités d'approvisionnement (*Provisioning engine*) et de gestion d'accès (*Access Manager*).
|
||||
|
||||
Le moteur d'approvisionnement, fourni par Syncope, est responsable des fonctionnalités de synchronisation des différentes bases de référentiels d'identité, avec toutes les problématiques de compatibilité (formats, modèles, sémantiques) qui en résultent.
|
||||
|
||||
Le gestionnaire d'accès se charge de l'authentification, des autorisation et de la fédération des identités fournies aux différents services de l'architecture.
|
||||
|
||||
Cf `syncope_architecture.png`. Description de la pile logicielle usuelle d'une appli Web utilisant Syncope.
|
||||
Syncope -> partie 'Core', du front au back en assurant aussi la sécurité.
|
||||
|
||||
//TODO CF Activiti BPM
|
||||
|
||||
La persistence est assurée par JPA, et les propriétés ACID du stockage sont prises en charge par le système transactionnel du framework Spring.
|
||||
|
||||
Connecteurs : ConnId pour l'implémentation des connecteurs
|
||||
Post SUN ICF (Identity Connector Framework)
|
||||
|
||||
Penser à installer les trois paquets Debian (la base, 'console', et 'enduser')
|
||||
|
||||
Installation de la GUI en client lourd ? Vraiment nécessaire ?
|
||||
|
||||
`http://localhost:8080/syncope-console/login?1`
|
||||
|
||||
TODO Tuto Apache Maven
|
||||
#### Apache Maven
|
||||
Outil de gestion de projet (au sens de gestion technique: résolution des dépendances, automatisation du build, packaging, génération de la doc, etc)
|
||||
|
||||
`JAVA_HOME` utilisé /usr/lib/jvm/java-1.8.0-openjdk-amd64
|
||||
Faire les modification dans /etc/profile
|
||||
Fichier lu au démarrage d'un login shell
|
||||
|
||||
Installation :
|
||||
Fichier binaire directement disponible
|
||||
Penser à rajouter le répertoire d'installation de Maven au $PATH
|
||||
|
||||
Il convient maintenant de configurer proprement Maven
|
||||
|
||||
`# OpenJDK environment configuration`
|
||||
`export JAVA_HOME="/usr/lib/jvm/java-1.8.0-openjdk-amd64"`
|
||||
`export PATH=$JAVA_HOME/bin:$PATH`
|
||||
`# Add Maven to the binary search path`
|
||||
`export PATH=/opt/apache-maven-3.3.9/bin:$PATH`
|
||||
`export MAVEN_OPTS="-XMs256m -Xmx512m"`
|
||||
Dernière options pour définir l'utilisation RAM de la VM Java
|
||||
|
||||
TODO en quoi Maven va plus loin que Ant pour ce qui est du build ?
|
||||
|
||||
#### Lancement de Syncope
|
||||
Création du projet à l'aide des *archetypes* Maven.
|
||||
|
||||
`/opt/apache-maven-3.3.9/bin/mvn archetype:generate \`
|
||||
` -DarchetypeGroupId=org.apache.syncope \`
|
||||
` -DarchetypeArtifactId=syncope-archetype \`
|
||||
` -DarchetypeRepository=http://repo1.maven.org/maven2 \`
|
||||
` -DarchetypeVersion=2.0.2`
|
||||
|
||||
Manipulation de fichiers POM
|
||||
|
||||
`paul@spare:~/Documents/syncope.test/synctest$ find ./ -name '*.war'`
|
||||
`./core/target/syncope.war`
|
||||
`./console/target/syncope-console.war`
|
||||
`./enduser/target/syncope-enduser.war`
|
||||
|
||||
Utilisation des profils Maven (option CLI '-P'), par exemple pour le mode *embedded* pour la partir enduser de Syncope
|
||||
|
||||
|
||||
Première constatation : niveau performances de l'interface Web d'administration, c'est vraiment trop lent.
|
||||
Pb inhérent à Java ?
|
||||
|
||||
Système de contrôle d'accès lui aussi défini par des rôles
|
||||
On parle aussi de relations (*Relationships*) pour définir les ressources auxquelles un utilisateur a accès.
|
||||
Ces ressources peuvent être internes ou non au groupe.
|
||||
|
||||
Pb : inutilisable en l'état : Unknown [ActivitiObjectNotFoundException: execution 10 doesn't exist]
|
||||
Exception non capturée dans le code
|
||||
Impossible d'utiliser l'interface d'administration
|
||||
|
||||
TODO : Troobleshoot + étudier cas de synchro de réfs d'identités hétérogènes.
|
||||
|
||||
Aller investiguer dans http://localhost:9080/syncope/db.jsp pour comprendre le modèle de stockage des identités mis en place par syncope
|
||||
|
||||
|
||||
### evolveum midPoint
|
||||
Projet écrit un Java, difficilement interfaçable avec les outils entr'ouvert.
|
||||
Lourd (projet git de taille 230Mo)
|
||||
Multifonctions :
|
||||
- Automatisation de la création (*provisioning*) et suppression (*deprovisioning*) des référentiels d'identité gérés.
|
||||
- synchro et gestion des conflits (*reconciliation*)
|
||||
- Automatisation des processus d'acceptation des requêtes au référentiel d'identité
|
||||
- Contrôle d'accès défini par les rôles (*Role-based access control* ou RBAC)
|
||||
- Outils de monitoring
|
||||
- utilisation de connecteurs standards pour interfacer les SP en tant qu'IDP
|
||||
TODO Parcourir sources, identifier les modules correspondant aux fonctions proposées
|
||||
|
||||
Installation à partir des sources, à l'aide de Maven
|
||||
|
||||
Déploiement d'un WAR de façon automatique avec tomcat ?
|
||||
Ne fonctionne pas pour l'instant
|
||||
|
||||
Problème de taille de mémoire allouée à la JVM ?
|
||||
Réessayer avec le manager GUI de tomcat (`/manager`)
|
||||
|
||||
Résolution : définition correcte du `MIDPOINT_HOME` dans `$CATALINA_HOME/setenv.sh` (script à créer)
|
||||
|
||||
### Linagora LinID
|
||||
Leur serveur ruby on rails (linid.org) est par terre pour le moment.
|
||||
|
||||
### ForgeRock OpenIDM
|
||||
Pour l'instant, impossible de le faire fonctionner, documentation trop light.
|
||||
|
||||
Lecture des sources et de la documentation
|
||||
Projet Java open source, dépôt git
|
||||
|
||||
Synchronisation de référentiels d'identités hétérogènes, par exemple Active Directory (Microsoft), OpenLDAP ou encore OpenDJ
|
||||
-> Les schémas ne sont pas les mêmes.
|
||||
|
||||
Mécanismes de correction des erreurs dans le référentiel, y compris lors de la phase de synchronisation
|
||||
Mise à disposition de 'nightly builds' (~versions Beta)
|
||||
|
||||
Pré-requis pour l'installation
|
||||
Windows ou Linux
|
||||
Java 7 ou 8 (JRE ou JDK)
|
||||
|
||||
#### Processus de synchronisation des référentiels d'identité
|
||||
Exemple donné entre Ressources Humaines et Pôle technique
|
||||
Un fichier csv et un fichier xml
|
||||
Le mapping entre les attributs des entrées du premier référentiel vers celles du second doit cependant être explicitement configuré pour mener à bien la synchronisation.
|
||||
|
||||
Fichier sync.json : liste de dictionnaires contenant deux entrées seulement
|
||||
'source' et 'target'
|
||||
```
|
||||
"properties" : [
|
||||
{
|
||||
"source" : "Name",
|
||||
"target" : "name"
|
||||
},
|
||||
{
|
||||
"source" : "lastName",
|
||||
"target" : "lastname"
|
||||
},
|
||||
{
|
||||
"source" : "firstName",
|
||||
"target" : "firstname"
|
||||
},
|
||||
{
|
||||
"source" : "email",
|
||||
"target" : "email"
|
||||
},
|
||||
{
|
||||
....
|
||||
}
|
||||
```
|
||||
|
||||
Serveur HTTPS, avec interface Web d'administration
|
||||
|
||||
#### Business processes, workflows
|
||||
Auto-enregistrement (*self-registration*)
|
||||
Certification des comptes (*account certification*)
|
||||
|
||||
Integration de l'outil libre Activiti
|
||||
respect de la norme BPMN (Business Process Model and Notation) 2.0
|
||||
|
||||
Prise en charge de la gestion des mots de passe. La degré d'exigence de la politique de sécurité des mots de passe est paramétrable. (Motifs interdits dans les passwords, date de validité, gestion d'un historique pour éviter la réutilisation des mots de passe).
|
||||
//TODO si nécessaire, cf chapitre 4.5 'Managing passwords'
|
||||
|
||||
Notion de rôle, en tant que scénario utilisateur TODIG
|
||||
|
||||
Schema XMI et XSD du protocole BPMN disponibles à :
|
||||
http://www.omg.org/spec/BPMN/2.0/
|
||||
|
||||
#### Connecteur fournis avec l'application
|
||||
|
||||
Google WebApps
|
||||
Salesforce ?
|
||||
LDAPv3
|
||||
CSV
|
||||
Databases
|
||||
|
||||
Plus intéressant : OpenIDM scripted connector framework
|
||||
Implémentation d'un connecteur sous forme d'un ensemble de scripts
|
||||
Connecteur hétéroclite dont l'interface est imposée par OpenIDM
|
||||
|
||||
Groovy Connector Toolkit
|
||||
Groovy: langage pour la plateforme Java
|
||||
Projet maintenu par la communauté Apache
|
||||
|
||||
#### Gestion/resolution des conflits de synchronisation
|
||||
aka reconciliation
|
||||
La politique de résolution des conflits de synchro entre deux (ou plus de deux) référentiels d'identités est configurable par l'administrateur de OpenIDM
|
||||
|
||||
|
||||
|
||||
#### OpenIDM Sample Files
|
||||
Description de cas d'utilisation dans des fichiers d'échantillon. Plusieurs cas décrit : //TODIG
|
||||
- Gestion de résolution de conflit sur des données utilisateurs stockées sur un fichier XML
|
||||
- Scripts de génération des messages de logs de l'application (y compris messages de debug)
|
||||
- Resolution asynchrone de conflits à l'aide de *workflows*
|
||||
|
||||
#### API RESTful
|
||||
TODO
|
||||
|
||||
#### Artefacts (*Artifacts*)
|
||||
TODO
|
||||
"Artifacts handled by OpenIDM are Java object representations of the JavaScript object model as defined by JSON."
|
||||
Comprendre le fonctionnement des artefacts
|
||||
|
||||
BIG TODO : faire tourner l'appli...
|
||||
|
||||
# SSO (et SLO)
|
||||
|
||||
# Synchronisation
|
||||
|
|
|
|||
|
|
@ -93,6 +93,315 @@ Héberger complètement un outil : maîtrise technique supérieure qu'un simple
|
|||
# État de l’art de la gestion des identités numériques
|
||||
|
||||
## Les solutions libres pour la synchronisation et l’approvisionnement des référentiels d’identités numériques
|
||||
### Authentic 2
|
||||
écrit en Django
|
||||
TODO Installation et déploiement en local
|
||||
TODO Ecriture d'un dummy SP pour tester Authentic ??
|
||||
|
||||
TODO Expliquer les particularités de la licence GNU Affero GPL (APGL) :
|
||||
- l'utilisation du code pour des applications Web déployées est pris en compte dans le caractère transitif ("contaminant") de la licence.
|
||||
TODO Quel intérêt de licencier la documentation sous Creative Commons ?
|
||||
#### Documentation
|
||||
Comprendre l'interaction avec Lasso pour le support SAMLv2
|
||||
|
||||
One-time password support ?
|
||||
|
||||
Sphinx, génération de la doc
|
||||
Cf structure des fichiers rst
|
||||
|
||||
##### Administration
|
||||
L'administration d'Authentic 2 se fait de façon classique, à l'aide du module d'administration de Django, lequel propose une interface graphique disponible à la page `/admin/` du site.
|
||||
Il faudra cependant veiller à créer un *superuser* lors de l'initialisation de la base.
|
||||
|
||||
Le contrôle d'accès aux ressources Authentic se fait par recours à deux politiques globales appelées 'Default' et 'All'. //TODO reformuler
|
||||
Le mécanisme de politiques d'accès géré par Authentic est extensible : l'administrateur du service peut en définir, en plus des politiques 'Default' et ' All'.
|
||||
|
||||
Le niveau de granularité de ces politiques est l'objet : à chaque objet il est possible d'attribuer une politique d'accès. // Au sens de la POO ?
|
||||
|
||||
//TODO Pourquoi est-il nécessaire d'appliquer la politique 'All' sur tous les objets ? Quel(s) problème(s) si on ne le fait pas ?
|
||||
|
||||
##### Gestion des attributs SAML2
|
||||
Il s'agit ici de configurer une politique de gestion des attributs envoyés dans les réponses de succès d'authentification envoyées par Authentic 2 aux SPs.
|
||||
|
||||
L'utilisation des attributs SAML2 dans les réponses Authentic varie en fonction des cas d'utilisation, Authentic peut ou on être configuré en tant que SP SAML2.
|
||||
|
||||
//TODO Relire `attribute_management.rst`
|
||||
Ligne 207 : une associe une politique à un SP
|
||||
Cas particulier du SSO
|
||||
Revoir scenario d'utilisation avec mire de connexion
|
||||
|
||||
##### Authentification
|
||||
Avec LDAP ou laissée à PAM
|
||||
Rappel: la configuration de PAM sous UNIX se fait à l'aide des fichiers situés dans `/etc/pam.d`
|
||||
|
||||
Configuration de la variable `AUTHENTICATION_BACKEND` du `settings.py` des sources Django.
|
||||
|
||||
##### SAML2 et croisement des données entre différents compte
|
||||
Cette possibilité de croisement des données entres les différents comptes liéss à une même identité est au coeur de la fédération d'identité (On parle de *account linking consent*).
|
||||
|
||||
C'est le fournisseur d'identité (IdP) qui gère le consentement des utilisateurs à la liaison de leurs différents comptes.
|
||||
Les données ne sont pas forcément croisées, il peut simplement s'agir de la mise en place d'un mécanisme de SSO.
|
||||
|
||||
Dans ce cas, le message SAML AuthnRequest contient un champ indiquant le choix de l'utilisateur quant au croisement des ses comptes.
|
||||
|
||||
Si l'IdP manipule des identifiants opaques (*transient*), alors le consentement de l'utilisateur au croisement des comptes n'est pas nécessaire. //TODO à vérifier
|
||||
|
||||
On notera aussi que le fournisseur de service (SP) est en droit de refuser un SSO valide si le consentement de l'utilisateur n'a pas été recueilli. //S'agit-il ici de Authentic en tant que SP ?
|
||||
|
||||
Il faut aussi gérer le consentement à la redirection d'attributs (*attribute forwarding consent*).
|
||||
Dans Authentic 2, cette politique de gestion consiste en un choix parmi trois possibilités :
|
||||
* Ne pas demander à l'utilisateur son accord
|
||||
* Recueillir un consentement global pour l'ensemble des attributs ("Tout ou rien")
|
||||
* Permettre à l'utilisateur de choisir, attribut par attribut, ceux qui peuvent être redirigés
|
||||
|
||||
#### authentic2-ctl
|
||||
installation par pip en local
|
||||
pip install ./
|
||||
Outil d'administration en ligne de commande
|
||||
|
||||
#### Installation
|
||||
* AttributeError: 'module' object has no attribute 'PassThroughManager'
|
||||
quand : utilisation de authentic2-ctl
|
||||
pourquoi : incompatibilité sur les versions récentes du module django-model-utils
|
||||
solution : rétrograder le module django-model-utils à une version <= 2.3
|
||||
|
||||
##### virtualenv Python
|
||||
Le mécanisme de création d'environnements virtuels sous Python permet de faire cohabiter sur un même système des installations disparates. Par exemple, un même module Python peut être présent en différentes versions tant que ces versions se situent dans des environnements virtuels différents.
|
||||
|
||||
Les répertoires d'installation des modules Python dans le cadre d'un virtualenv sont seulement locaux à l'environnement créé.
|
||||
|
||||
##### Troubleshooting
|
||||
-
|
||||
|
||||
|
||||
##### Utilisation des *tenants* du SGBDR
|
||||
|
||||
### Apache Syncope
|
||||
Syncope est le projet d'outil de gestion des identités numériques de la fondation Apache.
|
||||
Il est écrit en J2E et est distribué sous licence Apache.
|
||||
|
||||
L'identité numérique consiste en un ensemble de demandes qu'un sujet numérique peut effectuer à propos de lui-même.
|
||||
|
||||
Notion de cycle de vie des données d'identité telle que définie par le projet, à travers le *provisioning* et le *deprovisioning*.
|
||||
|
||||
//TODO Inclure image du projet Apache Syncope
|
||||
|
||||
|
||||
#### Tuto officiel (*Getting Started*)
|
||||
La problématique centrale de GI telle que le conçoit Syncope est
|
||||
"Qui a accès à Quoi, Quand, Comment et Pourquoi ?"
|
||||
|
||||
Trois types d'objet sont définis par Apache Syncope : les utilisateurs (*Users*), les groupes (*Groups*), et d'autres objets n'appartenant pas à ces deux premières classes, par l'introduction des objets de type *Any*.
|
||||
|
||||
Plusieurs techno différentes sont nécessaires dans un scenario de gestion des identités avec Syncope.
|
||||
Comme la plupart des IdM, Syncope nécessite l'utilisation d'un outil de stockage des identités (*Identity Store*). Il peut s'agir d'un SGDBR, d'un annuaire LDAP ou même d'un fichier "à plat".
|
||||
Syncope prend en charge les fonctionnalités d'approvisionnement (*Provisioning engine*) et de gestion d'accès (*Access Manager*).
|
||||
|
||||
Le moteur d'approvisionnement, fourni par Syncope, est responsable des fonctionnalités de synchronisation des différentes bases de référentiels d'identité, avec toutes les problématiques de compatibilité (formats, modèles, sémantiques) qui en résultent.
|
||||
|
||||
Le gestionnaire d'accès se charge de l'authentification, des autorisation et de la fédération des identités fournies aux différents services de l'architecture.
|
||||
|
||||
Cf `syncope_architecture.png`. Description de la pile logicielle usuelle d'une appli Web utilisant Syncope.
|
||||
Syncope -> partie 'Core', du front au back en assurant aussi la sécurité.
|
||||
|
||||
//TODO CF Activiti BPM
|
||||
|
||||
La persistence est assurée par JPA, et les propriétés ACID du stockage sont prises en charge par le système transactionnel du framework Spring.
|
||||
|
||||
Connecteurs : ConnId pour l'implémentation des connecteurs
|
||||
Post SUN ICF (Identity Connector Framework)
|
||||
|
||||
Penser à installer les trois paquets Debian (la base, 'console', et 'enduser')
|
||||
|
||||
Installation de la GUI en client lourd ? Vraiment nécessaire ?
|
||||
|
||||
`http://localhost:8080/syncope-console/login?1`
|
||||
|
||||
TODO Tuto Apache Maven
|
||||
#### Apache Maven
|
||||
Outil de gestion de projet (au sens de gestion technique: résolution des dépendances, automatisation du build, packaging, génération de la doc, etc)
|
||||
|
||||
`JAVA_HOME` utilisé /usr/lib/jvm/java-1.8.0-openjdk-amd64
|
||||
Faire les modification dans /etc/profile
|
||||
Fichier lu au démarrage d'un login shell
|
||||
|
||||
Installation :
|
||||
Fichier binaire directement disponible
|
||||
Penser à rajouter le répertoire d'installation de Maven au $PATH
|
||||
|
||||
Il convient maintenant de configurer proprement Maven
|
||||
|
||||
`# OpenJDK environment configuration`
|
||||
`export JAVA_HOME="/usr/lib/jvm/java-1.8.0-openjdk-amd64"`
|
||||
`export PATH=$JAVA_HOME/bin:$PATH`
|
||||
`# Add Maven to the binary search path`
|
||||
`export PATH=/opt/apache-maven-3.3.9/bin:$PATH`
|
||||
`export MAVEN_OPTS="-XMs256m -Xmx512m"`
|
||||
Dernière options pour définir l'utilisation RAM de la VM Java
|
||||
|
||||
TODO en quoi Maven va plus loin que Ant pour ce qui est du build ?
|
||||
|
||||
#### Lancement de Syncope
|
||||
Création du projet à l'aide des *archetypes* Maven.
|
||||
|
||||
`/opt/apache-maven-3.3.9/bin/mvn archetype:generate \`
|
||||
` -DarchetypeGroupId=org.apache.syncope \`
|
||||
` -DarchetypeArtifactId=syncope-archetype \`
|
||||
` -DarchetypeRepository=http://repo1.maven.org/maven2 \`
|
||||
` -DarchetypeVersion=2.0.2`
|
||||
|
||||
Manipulation de fichiers POM
|
||||
|
||||
`paul@spare:~/Documents/syncope.test/synctest$ find ./ -name '*.war'`
|
||||
`./core/target/syncope.war`
|
||||
`./console/target/syncope-console.war`
|
||||
`./enduser/target/syncope-enduser.war`
|
||||
|
||||
Utilisation des profils Maven (option CLI '-P'), par exemple pour le mode *embedded* pour la partir enduser de Syncope
|
||||
|
||||
|
||||
Première constatation : niveau performances de l'interface Web d'administration, c'est vraiment trop lent.
|
||||
Pb inhérent à Java ?
|
||||
|
||||
Système de contrôle d'accès lui aussi défini par des rôles
|
||||
On parle aussi de relations (*Relationships*) pour définir les ressources auxquelles un utilisateur a accès.
|
||||
Ces ressources peuvent être internes ou non au groupe.
|
||||
|
||||
Pb : inutilisable en l'état : Unknown [ActivitiObjectNotFoundException: execution 10 doesn't exist]
|
||||
Exception non capturée dans le code
|
||||
Impossible d'utiliser l'interface d'administration
|
||||
|
||||
TODO : Troobleshoot + étudier cas de synchro de réfs d'identités hétérogènes.
|
||||
|
||||
Aller investiguer dans http://localhost:9080/syncope/db.jsp pour comprendre le modèle de stockage des identités mis en place par syncope
|
||||
|
||||
|
||||
### evolveum midPoint
|
||||
Projet écrit un Java, difficilement interfaçable avec les outils entr'ouvert.
|
||||
Lourd (projet git de taille 230Mo)
|
||||
Multifonctions :
|
||||
- Automatisation de la création (*provisioning*) et suppression (*deprovisioning*) des référentiels d'identité gérés.
|
||||
- synchro et gestion des conflits (*reconciliation*)
|
||||
- Automatisation des processus d'acceptation des requêtes au référentiel d'identité
|
||||
- Contrôle d'accès défini par les rôles (*Role-based access control* ou RBAC)
|
||||
- Outils de monitoring
|
||||
- utilisation de connecteurs standards pour interfacer les SP en tant qu'IDP
|
||||
TODO Parcourir sources, identifier les modules correspondant aux fonctions proposées
|
||||
|
||||
Installation à partir des sources, à l'aide de Maven
|
||||
|
||||
Déploiement d'un WAR de façon automatique avec tomcat ?
|
||||
Ne fonctionne pas pour l'instant
|
||||
|
||||
Problème de taille de mémoire allouée à la JVM ?
|
||||
Réessayer avec le manager GUI de tomcat (`/manager`)
|
||||
|
||||
Résolution : définition correcte du `MIDPOINT_HOME` dans `$CATALINA_HOME/setenv.sh` (script à créer)
|
||||
|
||||
### Linagora LinID
|
||||
Leur serveur ruby on rails (linid.org) est par terre pour le moment.
|
||||
|
||||
### ForgeRock OpenIDM
|
||||
Pour l'instant, impossible de le faire fonctionner, documentation trop light.
|
||||
|
||||
Lecture des sources et de la documentation
|
||||
Projet Java open source, dépôt git
|
||||
|
||||
Synchronisation de référentiels d'identités hétérogènes, par exemple Active Directory (Microsoft), OpenLDAP ou encore OpenDJ
|
||||
-> Les schémas ne sont pas les mêmes.
|
||||
|
||||
Mécanismes de correction des erreurs dans le référentiel, y compris lors de la phase de synchronisation
|
||||
Mise à disposition de 'nightly builds' (~versions Beta)
|
||||
|
||||
Pré-requis pour l'installation
|
||||
Windows ou Linux
|
||||
Java 7 ou 8 (JRE ou JDK)
|
||||
|
||||
#### Processus de synchronisation des référentiels d'identité
|
||||
Exemple donné entre Ressources Humaines et Pôle technique
|
||||
Un fichier csv et un fichier xml
|
||||
Le mapping entre les attributs des entrées du premier référentiel vers celles du second doit cependant être explicitement configuré pour mener à bien la synchronisation.
|
||||
|
||||
Fichier sync.json : liste de dictionnaires contenant deux entrées seulement
|
||||
'source' et 'target'
|
||||
```
|
||||
"properties" : [
|
||||
{
|
||||
"source" : "Name",
|
||||
"target" : "name"
|
||||
},
|
||||
{
|
||||
"source" : "lastName",
|
||||
"target" : "lastname"
|
||||
},
|
||||
{
|
||||
"source" : "firstName",
|
||||
"target" : "firstname"
|
||||
},
|
||||
{
|
||||
"source" : "email",
|
||||
"target" : "email"
|
||||
},
|
||||
{
|
||||
....
|
||||
}
|
||||
```
|
||||
|
||||
Serveur HTTPS, avec interface Web d'administration
|
||||
|
||||
#### Business processes, workflows
|
||||
Auto-enregistrement (*self-registration*)
|
||||
Certification des comptes (*account certification*)
|
||||
|
||||
Integration de l'outil libre Activiti
|
||||
respect de la norme BPMN (Business Process Model and Notation) 2.0
|
||||
|
||||
Prise en charge de la gestion des mots de passe. La degré d'exigence de la politique de sécurité des mots de passe est paramétrable. (Motifs interdits dans les passwords, date de validité, gestion d'un historique pour éviter la réutilisation des mots de passe).
|
||||
//TODO si nécessaire, cf chapitre 4.5 'Managing passwords'
|
||||
|
||||
Notion de rôle, en tant que scénario utilisateur TODIG
|
||||
|
||||
Schema XMI et XSD du protocole BPMN disponibles à :
|
||||
http://www.omg.org/spec/BPMN/2.0/
|
||||
|
||||
#### Connecteur fournis avec l'application
|
||||
|
||||
Google WebApps
|
||||
Salesforce ?
|
||||
LDAPv3
|
||||
CSV
|
||||
Databases
|
||||
|
||||
Plus intéressant : OpenIDM scripted connector framework
|
||||
Implémentation d'un connecteur sous forme d'un ensemble de scripts
|
||||
Connecteur hétéroclite dont l'interface est imposée par OpenIDM
|
||||
|
||||
Groovy Connector Toolkit
|
||||
Groovy: langage pour la plateforme Java
|
||||
Projet maintenu par la communauté Apache
|
||||
|
||||
#### Gestion/resolution des conflits de synchronisation
|
||||
aka reconciliation
|
||||
La politique de résolution des conflits de synchro entre deux (ou plus de deux) référentiels d'identités est configurable par l'administrateur de OpenIDM
|
||||
|
||||
|
||||
|
||||
#### OpenIDM Sample Files
|
||||
Description de cas d'utilisation dans des fichiers d'échantillon. Plusieurs cas décrit : //TODIG
|
||||
- Gestion de résolution de conflit sur des données utilisateurs stockées sur un fichier XML
|
||||
- Scripts de génération des messages de logs de l'application (y compris messages de debug)
|
||||
- Resolution asynchrone de conflits à l'aide de *workflows*
|
||||
|
||||
#### API RESTful
|
||||
TODO
|
||||
|
||||
#### Artefacts (*Artifacts*)
|
||||
TODO
|
||||
"Artifacts handled by OpenIDM are Java object representations of the JavaScript object model as defined by JSON."
|
||||
Comprendre le fonctionnement des artefacts
|
||||
|
||||
BIG TODO : faire tourner l'appli...
|
||||
|
||||
|
||||
# Prise en main des technologies
|
||||
|
||||
|
|
|
|||
Reference in New Issue