Generic app integration with IDM using the Integration Module for DatabasesE. Axel Larsson

Drew Universityelarsson@drew.eduTTP 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

Integration Module for UNIX/Linux Scriptable framework for the bi-directional driver

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)

LAMP apps that don’t integrate with a directory. Discussion forums, online communities, open source

portals (at Drew – vBulletin forums)

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) “Indirect” synchronization

Database tables created in between the app tables and IDM.

Duplication of data from IDM tables to app tables (triggers)

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) Publisher channel:

Event Log table (triggers on underlying app objects to populate)

Alternative: Triggerless publication

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.

1 “child” table for each MV attribute. Two columns, foreign key to parent table, and

unconstrained value column. Foreign key constraint must be explicitly defined.

Indirect Synchronization (cont’d) Related attributes

Map to DN type attributes in eDir. Use foreign key references.

Data synchronization. Triggers to move data between app tables and

IDM tables. Event log triggers for publication.

Which should I use?

App is primarily a publisher of data. Direct sync tends to be less invasive. Triggerless publication in JDBC 2.x.

App is primarily a subscriber. Indirect may be easier, because INSTEAD OF triggers can

be a hassle. Other considerations

Isolation Delegation of development responsibilities. App vendor comfort levels / support.

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. MyISAM type tables, no foreign key support.

No MV attributes.

Questions?

E. Axel LarssonDrew Universityelarsson@drew.edu