Identity Registries and Reconciliation Posture


A vendor recently asked me a question, and not for the first time, that amounted to “why won’t you buy these delicious software licenses for our amazing identity-management suite, which provides comprehensive solutions to the challenges faced by North American corporations in dealing with compliance requirements and bringing together disconnected versions of identity from across all your application systems to create sparkling, delicious, and reliable golden-record representations of all your people-constituents?” and “why is identity reconciliation so undesirable?“.

The short answer takes the form:

  1. we have a strong single-identity model
  2. we do not need reconciliation
  3. we are a higher-educational insitution
  4. we are not a North American corporation

…and the longer answer emphasises that it’s notsomuch that identity reconciliation is undesirable, more that it’s an identity-registry posture that isn’t very useful in our context.

At a gross level, there are two primary identity-registry postures, each of which can be heavyweight (i.e., all identity attributes are involved) or lightweight (only identifiers and core personal data are involved), and they are:

  • Reconciliation: Identity lifecycles take place within independent silos across a suite of application systems (e.g., Human Resources, Customer Relationship Management, Student Administration, Library, Alumni, etc) and the identity-registry reconciles those identities centrally to produce an after-the-fact analytics-based golden record (which can be used to enable single-sign-on and for roles reconciliation and compliance reporting and so forth).
  • Mastering: Identity lifecycles take place only in a central identity-registry system-of-record, and all changes affecting those identities are propagated (sometimes through an intermediary such as an LDAP directory, sometimes through publish-and-subscribe messaging, and sometimes through SAML attributes) to those downstream application systems that require identity information.

The decades-old strong single-identity model in my organisation is sustained by a heavyweight-mastering identity-registry.

As new application systems are introduced into the organisation, they are configured to prevent local/downstream changes being made to any identity information (all of which is mastered in the central identity-registry) and integrated, by one means or another, to receive only the identity information they require.

Roles, though, are another kettle of fish, and those that cannot be derived (e.g., from system-of-record information about states such as employment or enrolment information) tend to be managed locally, application-system-by-application-system.  This makes tracking the currency (e.g., is this person still entitled to this privilege?) and appropriateness (e.g., are there segregation-of-duties conflicts occurring across multiple application systems?) tricky.  As a result, there is some good value available from roles reconciliation — that is, bringing roles information together into a central repository for reporting, analysis, compliance, and for springboard-provisioning of access to extended systems-and-services.



Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s