2

IAM Design Principle: Don’t make decisions on an absence of data

Share this content:
LinkedIn
Facebook
RSS

 

I’ve been going on about this one for a long time, but in case anyone still isn’t onboard with this principal I’ll state it another way: data disappearing from a feed is not a suitable trigger for action.

When we treat disappearance of data as a “trigger” we are interpreting a root cause from a received effect. We are saying “there can only ever be one possible reason why this piece of data has gone missing from our feed” – but is that really the case?

I’ve been pushed (protesting loudly) down this path a few times, and sooner or later something always goes wrong. A technical glitch, a patch, a “we didn’t realise if we clicked that button those records would be removed from the feed”. It was so bad in one environment that I had to introduce a manual step checking up on “deletes” before allowing them to flow through to deactivations. Kind of removed the effectiveness of the automation!

I’ve also seen (and attempted) protective measures like confirming an extraction process ran without errors, checking for an “end of file” line, or even storing a line count to compare to next time… but these band-aids add complexity to the solution and sometimes cause problems in their own right. They can also lead to a false sense of security – I have had a data collection script work perfectly for two years, and then fail to retrieve all the data one time without reporting an error. That sort of thing may be pretty much impossible to predict or test, but where the consequences can be disruptive it’s just not worth the risk.

So this one stands: Actions in the IAM Solution should only ever be triggered on received data, and never on the source data disappearing.

 

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.

2 Comments

  1. Agree in principle, Carol. However this is a particularly tricky scenario to handle when dealing with a source of truth which surfaces a composite view of an identity (e.g. SQL view). For example you may have a SQL left join from PERSON to JOB which is responsible for say an IsActive boolean flag, and a Coalesce or IsNull SQL function to interpret a true or false value. In this case your sync solution rule may be to disable and rename a matched AD user, and you are thereby exposed to mass user disabling in AD if an unexpected SQL event such as the temporary delete/recreate of JOB data happens to occur at the time your sync service is reading from the SQL view. The point I am making here is that the SQL delete is actually surfaced as a USER modification from a sync perspective – thereby making exception trapping much less straight forward.

    I can only really see 2 practical approaches to this scenario:
    1. (easiest) implement a safety catch approach targeting changes to your specific IsActive attribute (see https://unifysolutions.jira.com/wiki/display/FIMTEAMCOM/2016-04-13+-+Disaster+Avoidance); and/or
    2. Treat the IsActive as “tri state” (true/false/null) and ensuring your sync solution recognises these 3 values and only actions the change on a join to say an end-dated job (as opposed to a missing job record).

    There is no hard-and-fast rule here – but the principle should always be to look beyond the obvious in your data feed and not treat it on face value only. Great advice Carol.

  2. Option 2 is the only way – require hard data to trigger deactivations. I think this is essential when talking about anything disruptive to end users, like deactivations. I’d only soften this rule on “decorative” attributes – eg we may not care if a person’s contact details go missing for a while and then re-appear. We may well care very much if their job details go missing if they also form the basis of RBAC.

Leave a Reply

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