Project Architecture: Identity Management

An overview of an identity management project I lead.

Auditing application access is an important aspect of securing an application. At a previous gig I was tech lead for ver 1.0 system that did exactly this.


  1. Monitor HR database for employment changes
  2. Notify administrators of 19 other systems (downstream systems) of employment status changes for their users.
  3. Record result of audit. (If the user was removed or not.)

From 30,000 feet the system would

  1. Keep a list of all employee records that had status changes from an arbitrary point in time forward.
  2. Match those records with user records from downstream systems.
  3. Present the matches in a web app to the system admins.
  4. Record if the user was removed
  5. Allow the admins to enter a note about why the user wasn’t removed.

The HR database is PeopleSoft on top of Oracle and the 19 other systems are mostly SQL Server but a few Oracle as well.

We built a few stored procs in Oracle to provide the relevant HR data and pumped it into a separate SQL database. This process was configured to run both periodically (app.config) and on demand through a web app.

The downstream systems posed some interesting constraints. First, they didn’t want to do any development. Second, we better not affect the performance of their system.

The architecture team butted in and required that we interface with the downstream systems through WCF. There are a number of benefits WCF provides. None of them applied to this system and the additional complexity slowed us down significantly. But that’s the way they wanted it.

Here is the architecture: