Rares sont les initiatives open source dans le domaine des outils de provisioning. Le framework ICF, initiative open source, mérite que nous y apportions toute notre attention. Simple, souple et efficace, ce framework permet à la fois d’accélérer les développements, mais également de les standardiser, réduisant ainsi les coûts de développement mais également la maintenance.
Découplage entre le moteur de provisioning et les applications cibles
La caractéristique majeure de ce framework consiste en l’introduction d’un découplage fort entre le moteur de provisioning et les applications cibles. Ce découplage est rendu possible par une architecture bi-couche permettant ainsi de séparer les appels (utilisation de la couche API) au connecteur de son implémentation (basée sur la couche SPI). API : Application Programming Interface SPI : Specific Provider Interface
La construction d’un connecteur consiste donc à implémenter un certain nombre d’interfaces SPI fournies en standard par le framework et en respectant les conventions imposées (convention over configuration). Le découplage entre les appels et l’implémentation permet avant tout de capitaliser sur le développement d’un connecteur puisqu’il peut être réutilisé avec un autre moteur de provisioning. Cela permet également d’envisager de mettre en place des tests unitaires et ainsi de valider presque entièrement les développements avant la phase d’intégration.
Deux autres caractéristiques majeures du framework
Extensibilité
Un connecteur basé sur le framework ICF peut être construit comme une extension d’un connecteur déjà existant, ce qui permet de capitaliser sur ce qui a déjà été développé et éviter la redondance de code. Dans le cas d’une application cible de type base de données relationnelle, il est envisageable de développer un premier connecteur générique contenant toute la logique d’accès, puis de l’étendre pour intégrer les spécificités d’une base de données spécifique (schéma, requêtes…).
Identity Connector Server
L’architecture ICF a été conçue afin de permettre la communication entre une application cliente et un connecteur déployé sur un serveur distinct. Cette architecture peut être adoptée lorsque des contraintes en termes de performances sont imposées. Cela donne également la possibilité d’envisager le développement d’un connecteur dans une technologie autre que Java (.NET par exemple) lorsque l’application cible est plus adaptée à un langage de programmation donné. C’est le cas d’Active Directory pour lequel le framework .NET est plus approprié.
Les avantages et les inconvénients
Inconvénients
- Peu de contributeurs et activité faible
- Manque de maturité des connecteurs standards
- Peu, voire pas de documentation
Avantages
- Léger et simple à mettre en œuvre
- Extensibilité
- Respect des design patterns (facade, factory…)
- Open source
- Adopté par un éditeur important dans le domaine de la gestion d’identités : Oracle
Liste des connecteurs proposés
Connecteurs Java
- CVS Directory
- Database table
- Flat file
- GoogleApps
- LDAP (v3)
- SOAP
- Active Directory
Connecteurs .NET
- Active Directory
- Exchange
ICF, en pratique
Depuis la version 11g d’OIM (Oracle Identity Manager), Oracle a fait le choix d’intégrer le framework ICF dans son architecture. La réécriture des connecteurs existants proposés en standard (Active Directory, LDAP…) s’appuiera à terme sur ce framework. L’éditeur préconise également son utilisation pour tout développement de connecteur en spécifique. Synetis a fait le choix de s’appuyer sur ce framework pour le développement de nouveaux connecteurs pour le compte d’un client ayant mis en œuvre la solution OIM. Le retour d’expérience est positif et nous encourage à poursuivre son adoption.In the world of identity and access management and with an array of products available in the market, the initiatives of the usage of open source are quite rare. As Oracle announced its newest release of OIM 11g, came running the buzz “ICF Framework”, an open source project that deserves an attention of all of us!!!
Simple, flexible and effective, this framework allows faster and standardized developments, reducing development cost and maintenance needs to a greater extent.
Provisioning engine and target applications segregation
The main characteristic of this framework is the introduction of a strong segregation between the provisioning engine and target applications.
This is now possible with the introduction of two-layer architecture, which allows the connector to be called from API (Application Programming Interface) layer separately from its implementation layer, i.e. the SPI (Service Provider Interface) layer.
Previously building the connector was primarily implementing the specific SPIs while respecting certain SPI specific imposition. Now with the introduction of ICF, it offers a flexible connector development along with the advantage of reusability with other provisioning. Additionally, it allows the developer to do the unit tests of each and every functionality of the connector prior to the integration to OIM 11g provisioning engine.
Two other major characteristics of the framework
Extensibility
A connector based on the ICF framework can be built as an extension of an existing connector, permitting additional benefits of the “already developed” components while avoiding code redundancy.
For the target applications like the relational database, it is now possible to do at first, developing a generic connector that contains all the basic access related logical codes and at the second, integrating and extending the generic connector to contain more specific implementations (specific query, calling a stored procedure or introduce a new schema) of the actual target database.
Identity Connector Server
The ICF architecture was created to allow communication between a client application and a connector deployed on the remote server. This way, it can be used even in an environment with performance cost constraints. It is very much possible now to develop a connector developed in a language and platform other than Java, to suit best to the target application. For example, a .net connector will be more suitable for an AD server than a java connector.
Pros and Cons
Cons
- Few contributions and low activity
- Standard connectors not quite mature yet
- Less (if no) documentation
Pros
- Light and simple to implement
- Extensible
- Uses design patterns
- Open source
- Used by a major player in the field of identity management : Oracle
List of available connectors
Java Connectors
- CVS Directory
- Database tables
- Flat file
- Google Apps
- LDAP (v3)
- SOAP
- Active Directory
.Net Connectors
- Active Directory
- Exchange
ICF in the field
The ICF framework now comes bundled with the release of OIM 11g. The existing connectors like for Active Directory, LDAP, etc. will be redeveloped to be ICF compliant in the near future. Oracle highly recommends ICF framework for developing custom connectors for OIM. The consultants at Synetis chose the development of connectors using ICF connector for one of its clients and are highly appreciated with good feedback. The experience of developing a connector in ICF has been highly motivated and encouraging.