Page History

...

Information about a user should include attributes as specified by the organization
Only the IdM system should be able to write to log/audit data stores
The IdM system must be able to associate user account data across multiple systems each having which may have different schemes for local identifiers
The IdM system needs to notify downstream systems of user-related events in a timely and secure fashion
The IdM system must consume upstream user-related events from systems of record in a timely and secure fashion
IdM functions may need to be invoked by remote systems using APIs for specific purposes

Standards Support and Integration Considerations

Where possible, avoid non-standard technologies which require specifically integrated vendor components to be deployed.

Design Look for designs of data integration components to be which are loosely coupled. Components which are loosely-coupled can bring flexibility and interoperability with products from different vendors.
Base user account data integration on the mapping of a meaning-free identifier. Use a meaning-free identifier to map to local user identifiers to facilitate working across multiple systems which each may use different schemes for the local identifiers.
Use Favor designs which use commodity message queuing products where possible. For example, use products such as Apache ActiveMQ for messaging needs.
Integration with downstream systems ideally should be asynchronous and loosely-coupled. For example, user provisioning can use event notification mechanisms with generic user account add/modify/delete event messages.
Expose Favor systems which expose IdM system functions as REST-based services for simplicity. Use REST-based services to allow such related systems as user administration or resource management applications to simply access IdM functions.