Principles for Identity Data

As you review, consolidate, and create identity data, there are several important principles that you should keep in mind. Some of these are adapted from The Practical Guide to Enterprise Architecture by James McGovern, et al. (Prentice Hall).

Don't replicate identities

Wherever possible, you should avoid replicating identity data and ask for it from its canonical source instead. For example, if you need the SSN for an application, it would be better to retrieve it using a SAML request or database query from the HR employee record.

Business requirements should drive identity replication

If you can't avoid replicating identity information, you should do so only because the business requirements force the replication. Application developer convenience is never a good reason for replication. One of the primary reasons for this principle is that identity data is often subject to internal and external audit, security, and privacy requirements that will have to be monitored and paid for by the business unit. Replicating identity data increases the cost of these external requirements and so that cost ought to be traded off against business requirements.

Replicated identities should be read-only

Break this principle at your own peril. As soon as multiple systems can change replicated data, the data will be guaranteed to be out of sync.

Identity data should be locationally transparent

Applications should be constructed so that they don't rely on the identity ...

Get Digital Identity now with the O’Reilly learning platform.

O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.