Sweet chewy nuggets of identity wisdom

Ashraf Motiwala offers up these nuggets of identity wisdom:

  • Good technology can’t compensate for bad processes (although it might make it less painful)
  • Fixing your data without fixing your processes is like painting your house on a rainy day
  • Throwing more software at an identity problem usually exacerbates it
  • A dollar in an identity project doesn’t take you as far as you’d expect (even though its well worth it)
  • What business users think is happening is quite often vastly different than what is happening under the hood

Ashraf also asks for more one liners. Here are my favorites:

  • The dirty little secret about provisioning is that it’s really all about deprovisioning.
  • You shouldn’t start out trying to do account management by adding another account to manage.

The former was drilled into me at Access360 when I repeatedly saw customers that were really ok with it taking an employee weeks to get access to all the required resources, but wanted them turned off the moment the decision had been made to end the employment relationship. The later is a reference to the large number of identity products that still can’t leverage an existing identity store for users, and instead synchronize an internal proprietary user repository.

One response to “Sweet chewy nuggets of identity wisdom

  1. Jeff,

    I just found your blog today from a link. Sorry I didn’t find it before.

    I’m curious about your last point about leveraging an existing identity store for users. Provisioning requires a great deal of data to make decisions. What existing identity store would do the job?

    I also wonder how, even if such a store existed, a provisioning solution would be able to retain a delta for a point of comparison in the event that native changes are made “out of band.”

    Lastly, due to compliance and audit requirements, customers want a history of access, while production identity stores are populated with only the current data, as that is all that is necessary for their run-time function of authentication and authorization.

    So, I am interested in what you have in mind with this comment. I agree that this internal repository shouldn’t be proprietary, but I do think a provisioning user repository is necessary.

    Kevin

Leave a comment