Generic app integration with IDM using the Integration Module for Databases
E. Axel Larsson Drew University elarsson@drew.edu TTP EMEA Conference 2007
“Generic” IDM drivers
Integration Module for Tools
Driver for Delimited Text SOAP Driver
Integration Module for Enterprise – Custom Edition
Extend Composer based drivers Scriptable framework for the bi-directional driver
Integration Module for UNIX/Linux
Integration Module for Databases
What is the Integration Module for Databases?
Integrates foreign applications with IDM directly at the database level, rather than app specific APIs. Supports subscriber and publisher channels
Subscriber events converted into SQL queries – INSERT, UPDATE, and DELETE actions. Publisher events based upon an event log or polling (i.e. triggerless publication)
Decision Criteria
Things to consider when evaluating whether to use the Integration Module for Databases
This is not a zero-impact solution
Driver imposes DB schema requirements Artifacts created in the application database – views, intermediate tables, triggers.
Application vendor comfort levels DBA comfort levels Schema stability Vendor provided APIs Database support for required features (i.e. triggers and views) – MySQL?
Types of Applications
Extend your IDM system beyond user account provisioning in different directory services.
Customer/patron databases
Helpdesk (at Drew – Supportworks) Campus card systems (at Drew – CS Gold) Discussion forums, online communities, open source portals (at Drew – vBulletin forums)
LAMP apps that don’t integrate with a directory.
Two deployment models
“Direct” synchronization
Views created in between the app database tables and IDM. Views must be updateable if the subscriber channel is to be used (INSTEAD OF triggers)
Database tables created in between the app tables and IDM. Duplication of data from IDM tables to app tables (triggers)
“Indirect” synchronization
Direct Synchronization
1 view for each object class. View exposes all attributes included in the driver filter. Primary/foreign key hints (pk_ prefixes, etc.) Subscriber channel:
View must be updateable (INSTEAD OF triggers) Event Log table (triggers on underlying app objects to populate) Alternative: Triggerless publication
Publisher channel:
Indirect Synchronization
Intermediate staging tables in between IDM and the application. 1 “parent” table for each object class.
Parent table contains all single valued attributes. Must have a primary key. Two columns, foreign key to parent table, and unconstrained value column. Foreign key constraint must be explicitly defined.
1 “child” table for each MV attribute.
Indirect Synchronization (cont’d)
Related attributes
Map to DN type attributes in eDir. Use foreign key references. Triggers to move data between app tables and IDM tables. Event log triggers for publication.
Data synchronization.
Which should I use?
App is primarily a publisher of data.
Direct sync tends to be less invasive. Triggerless publication in JDBC 2.x. Indirect may be easier, because INSTEAD OF triggers can be a hassle. Isolation Delegation of development responsibilities. App vendor comfort levels / support.
App is primarily a subscriber.
Other considerations
I use the indirect method.
What about MySQL 4.x?
Limitations of the database restrict its use with the IDM module for databases. No triggers, no views
Syncing directly to app tables. App database schema must conform to IDM needs. No MV attributes.
MyISAM type tables, no foreign key support.
Questions?
E. Axel Larsson Drew University elarsson@drew.edu