Transcript Generic app integration with IDM using the Integration

Generic app integration with
IDM using the Integration
Module for Databases
E. Axel Larsson
Drew University
[email protected]
TTP EMEA Conference 2007
“Generic” IDM drivers

Integration Module for Tools



Integration Module for Enterprise – Custom
Edition


Extend Composer based drivers
Integration Module for UNIX/Linux


Driver for Delimited Text
SOAP Driver
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.



App is primarily a subscriber.


Indirect may be easier, because INSTEAD OF triggers can
be a hassle.
Other considerations




Direct sync tends to be less invasive.
Triggerless publication in JDBC 2.x.
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 Larsson
Drew University
[email protected]