IAM Design Principle: The Source of Truth is the place where people care about the data being right

Share this content:

I’ve recently started a new project and we’re in the requirements gathering phase, so lots of meetings and discussions, and also (thankfully) enthusiasm for the project.

There’s also been lots of me repeating stuff I always say when trying to explain Good IAM Design, so I’ve decided to start a new series of short blog posts on the subject. There will be some overlap with an earlier series I did on FIM Best Practises, but I’ll be keeping this one product independent.

On IAM projects there is always a lot of talk about “source of truth”, along with a varying interpretations about what this actually means. My response is that “the source of truth is where people care about the data being right”, and then we aim to get as close to that data source as possible. I’ve written on this subject before: FIM Best Practice: Use the best Data Sources

However now I’d like to add an extra clause that “people care about the data when something breaks if it’s wrong”.

In recent years I’ve worked with a few organisations who have taken this whole Source of Truth thing too far, in that they have attempted to declare One Source to Rule Them All. I have seen the HR system made “authoritative” for what sort of user accounts people get, for application assignment, even for email address. Because HR systems are typically not designed for these applications strange and murky processes get built up on the HR side, as a way of sending smoke signals to the IAM solution. It’s complex and prone to human error – and the worst thing is, HR people don’t (and shouldn’t really have to ) care. If they perform these mystical IT-directed rites incorrectly nothing breaks for them. The processes they actually do care about (like people getting paid) work just fine.

So I’m extending the scope of this particular IAM Design principal:

The Source of Truth is where people care about the data being right, and bad stuff happens if it’s wrong, and they can fix it!


I will be adding to this series regularly between now and the end of December. Check back weekly to ensure you don’t miss any new posts!

Also, I would love to hear your thoughts on the topic, so please share them in a comment.

Carol Wapshere

I’ve been working in the IT industry for rather a lot of years now, starting in sys admin then moving through project work and consultancy, eventually coming across MIIS 2003 in 2005 while working on an email migration project in London. After a few years in Switzerland I am now back in Australia, based in Canberra, working for UNIFY Solutions. I have been awarded the MVP for ILM/FIM every year since 2009.


  1. Agree. In public sector, I really like teaching the concept of Authoritative (“source of truth”) versus Accountable Source (e.g., a birth certification is an authoritative source for Birth Data and a Driver’s License is an Accountable Source).

    Creating an Enterprise IAM resource as the Accountable Source where a unique entity digital identity record (DIR) is extended appropriately for Federating is a “best practice”.
    HR and/or Security are the Authoritative Sources for Person Entity data – but a centralized Accountable Source mission preps the digital identity to be federated and centrally managed, etc. The centralized Accountable Source feeds all Identity Providers and/or other relying parties and provides a centralized center of people-excellence to work the data issues and associated credential/attribute linking and enable association to provisioned resources, etc.
    As you outlined these leaves HR/Security people focused on their mission and allows “IAM” professionals to managed the core DIR within the scope their practice is comfortable with…

      • NP -I’m working a similar issue right now, stumbled across your article and it touched the nerve and I blathered. Another key distinction is that true Authoritative Sources can change the values associated to the data, whereas Accountable Sources should not be able to change the values associated the data, only tag per pre-defined agreements. Authoritative Data has a source of creation, should only be created once and then federated by a centralized Accountable Enterprise Agent… This paradigm preserved the confidence of the identity data per it’s intended operational usage.

        I’ll definitely follow your posts!

Leave a Reply

Your email address will not be published. Required fields are marked *