72 things I’ve learned about IAM

72 door-opening thoughts…

In 2006, after three years of working with an inflexible vendor to implement immature identity and access management technology, my client asked me to document some lessons learned from the projects.  I’ve done a couple of talks with these findings over the past few years and these lessons have influenced my approach to IAM project delivery ever since.

[Click here for a Prezi of this post…]

In the past few months, I’ve come across blog posts related to identity management best practices and lessons learned, such as this one from Mark Dixon. These observations mirrored my own in some ways, and differed in others, so I thought I’d put together a top 10 list things I’ve learned, including some useful advice on identity.

The only problem is that in preparing the list I cruised past 10, then 20 — and before long I had itemized 72 things that I’ve learned about IAM since I entered this niche seven years ago.

In keeping with the fashion of today, each entry will be 140 characters or less…

  1. IAM is a tool for business; it has little to do with technology.
  2. Business people are frequently shielded from making IAM decisions.  It is not clear why this is so.
  3. Develop an IAM strategy in 2010.
  4. If you aren’t ready for a strategy, consider an IAM assessment so you at least know where you are at.
  5. Products have improved greatly in the past seven years.
  6. Delivering IAM is still difficult — there are too many disciplines involved and not enough fundamental understanding.
  7. If not managed, all IAM business decisions would be driven by user convenience and process simplicity.
  8. Information security professionals need to influence these IAM implementation decisions.
  9. Some of the best resources for an IAM project are senior software developers.  Tech analysts often don’t get it.
  10. Information security analysts need to understand that IAM enables — they often get caught up on the protection bit.
  11. All IAM projects need business analysts.  Every. Single. Project.
  12. IAM should be delivered as a program, not a set of loosely connected projects.
  13. An IAM program needs deliberate governance and formal communication.  Just winging it won’t work…
  14. Build an IAM roadmap.
  15. New to IAM? Start small: proof-of-concept, then a pilot, then small app in production, then the big one (in stages).
  16. IAM needs to be driven by policies and standards — without these in place, IAM will flounder.
  17. Support IAM with good IT and security architecture.
  18. Many IAM experts I’ve come across online are  obsessed with technology and rarely link to the business.
  19. Avoid ocean boiling — leave fine-grained entitlements with the application to worry about (for now).
  20. Strong identity assurance is poorly understood.
  21. Strong authentication is useless without good identity assurance processes.
  22. Strong identity assurance processes are difficult without face-to-face identity validation.  But not impossible.
  23. A strong authentication device does not make a secure system.
  24. Strong passwords do not equate to strong authentication.
  25. By their actions, Canadian banks don’t understand strong authentication, but are masters at strong identity assurance.
  26. Many enterprises are still drinking RSA’s kool-aid and are blind to other strong authentication options.
  27. Some strong authentication technologies, such as smart cards, can get you into buildings.  Think convergence.
  28. Some web sites have silly ideas about passwords and security.
  29. Most senior execs do not understand how IAM can both protect and enable their core business.
  30. Most IT execs can’t explain how IAM can both protect and enable their core business.
  31. Most techs don’t understand how IAM enables business.
  32. Many vendors are starting to understand how IAM can both protect and enable their clients’ businesses.
  33. IAM is not just about electronic access — people access information in all kinds of ways, and from myriad locations.
  34. Two IAM geeks talking will induce lethargy on any bystander within ear-shot.
  35. IAM is an enabler for any organization that serves people with disabilities.
  36. IAM is largely being used for low value transactions.  ROI will sky-rocket when the important stuff comes along.
  37. In IAM, sometimes clicking ‘I Agree’ is not sufficient.  Blue ink on white paper can still be still necessary.
  38. Federated identity can cement business relationships — for good and bad.
  39. Federated identity excites people.
  40. Federated identity scares enterprises.
  41. Federated identity challenges are not technical — most issues are related to process and agreements.
  42. There will be a boom in the coming years for businesses that provide identity assurance services to enterprises.
  43. IAM systems collect way too much information for the access requirements of most business applications.
  44. IAM stores are gold mines for identity fraudsters.
  45. Pan-Canadian IdM&A still rocks, even if it is only partially developed and is horribly communicated.
  46. Canada is behind the US and Europe in IAM implementations.
  47. People still trust passwords even though they shouldn’t.
  48. The best book on identity is Jim Harper’s Identity Crisis.  Read it.
  49. Vague IAM prediction for 2012: Microsoft.
  50. IAM projects often get dragged into enterprise confusion about the identity information that they already hold.
  51. Young people are starting to become more privacy aware.  Slowly. And it is probably too late for most of them.
  52. There are no Canadian university researchers interested in identity. Zero.  None. (Are there?)
  53. American views of identity are heavily focused on protection.
  54. Canadian views on identity are heavily focused on privacy.
  55. IAM solutions for health care are difficult due to perceived and real risks.  The challenge is to know the difference.
  56. Identity can’t get in the way of delivering health services, even if it can link a patient to his/her records.
  57. A risk management approach must be taken towards all IAM projects.
  58. Security in layers for IAM solutions is a good thing, but poorly understood.
  59. Certifying IAM processes is critical if common identity assurance and authentication practices are to take hold.
  60. End users of IAM systems are more capable and responsible than we give them credit for.
  61. IAM systems are very difficult to make highly available — too many pieces.  But most apps don’t need high availability.
  62. Those that ask for IAM high availability often don’t have well-developed reasons for it.
  63. 90% of IAM traffic is authentication.
  64. 10% of the work in an IAM project is to figure out authentication and strong authentication.
  65. 10% of IAM traffic is related to registration/enrolment.
  66. 90% of the work in an IAM project is needed to build a compliant registration/enrolment sub-system that works.
  67. Copying a driver’s license to screen customers should result in more than an order from the privacy commissioner.
  68. Relying on existing data stores or directories for an IAM user store is risky — most user data is in terrible shape.
  69. Help desk staff must understand and follow formal identity assurance processes when dealing with IAM users over the phone.
  70. Having users self-register and self-enroll into business applications can be very effective.
  71. Powerful user-self administration is just around the corner.

and finally,

72. People are what matters in IAM, not ‘users’, ‘stakeholders’ or ‘customers’.  Think people and IAM gets easier.

Happy 2010!


Author: code

Mike Waddingham is senior Information Technology management consultant with over 30 years of industry experience. He is the owner of Code Technology Corp.

9 thoughts on “72 things I’ve learned about IAM”

  1. Hi Mike

    I found your article, “72 things I’ve learned about IAM” very interesting. I’m interested in knowing if you have any other thoughts surrounding your point #22:
    “Strong identity assurance processes are difficult without face-to-face identity validation. But not impossible.”
    I work with the Australian Attorney-general’s Department and we are working currently on developing policy on online enrolment for government services. There would seem to be a good argument for an online registration process to involve at least some subsequent face-to-face interaction in order to help mitigate identity fraud risk. Obviously, however, this then detracts from the advantages provided by online enrolment, such as lower registration costs. You indicate that face-to-face interaction may not be necessary. I’m interested in your thoughts on how this might be achieved.

    Best Regards

    Wayne Colless
    Identity Security Branch
    National Security Resilience Policy Division
    Attorney General’s Department

  2. Wayne, the model I was thinking of was that used by the Canadian passport office. Citizens can fill in an application (with very detailed information) accompanied by a photo that, along with the application, has been signed by a guarantor. That guarantor is usually a professional — engineer, physician, etc. — that pledges to have personally known the individual for at least two years. This package is sufficient for issuance of a passport.

    A friend of mine is an engineer and he tells me he’s been signing passport applications for many years — but only in the past few has he been contacted by the passport office to confirm his endorsement. Seems that they have had a need to tighten this process up recently…

    A model like this, based on corroboration of identity by a trusted third party, could be applied to a process that supports the issuance of a strong electronic credential. Of course, the delivery mechanism used to deliver that credential/token would need to be similarly strong — simply dropping it in the mail would not be sufficient.


  3. Mike,

    Very good lessons, I recall each point has relevance.
    Here are two more:
    73. Think life cycle; your system credential is your ticket to ride, but it can be revoked, may expire and it is never transferable.
    74. A system credential should always be bound to a real person, based on verifiable facts from a trusted source (yes trusted). No Avatars allowed no matter how fashionable!

    Thanks again for the insights!
    Bruce Coles

  4. I have a question about #25 “By their actions, Canadian banks don’t understand strong authentication, but are masters at strong identity assurance.”

    The linked post does demonstrate the first point (about authenticators), but doesn’t appear to mention identity assurance. Perhaps continuing the anchor text to the comma would suffice to clarify.

    I’m *really* interested in identity assurance (vetting) processes that work at scale and for non-in-person affiliates/customers, so I was a titch disappointed not to find that in the referenced post.


    1. jml,

      I haven’t had professional experience with banks yet, so my comments are from a customer standpoint. Canadian banks are good at strong identity assurance because they have a strong self-interest in knowing who you are before they lend you money. For this reason, they institute in-person identity checks that are followed up by credit checks. This combination of face-to-face with third party corroborated identity proofing approaches the highest level of identity assurance. In addition, the ‘Big 5’ banks have thousands of branches offering services in every part of the country so they can perform this identity proofing pretty much anywhere.

      I, too, am interested in strong identity assurance processes that can scale. I gather that there are an increasing number of identity verification services that could meet this need — or part of it, i.e. the corroboration bit. Add to this a certified online process that gathers and verifies the identity information (against already known information), throw in a decent audit framework, and you may get the large-scale proofing you are looking for. You should be able to achieve NIST Level 3 with such an approach.


  5. # In IAM, sometimes clicking ‘I Agree’ is not sufficient. Blue ink on white paper can still be still necessary.


    See the attached link as one example, although I believe similar laws exist across the world.

    1. Hi Tim,

      Regarding e-signature legislation, here is an interesting part from Alberta’s Electronic Transactions Act:

      …the legal requirement that the record be signed is satisfied by an electronic signature only if in light of all the circumstances
      (a) the electronic signature is reliable for the purpose of identifying the person, and
      (b) the association of the electronic signature with the relevant record is reliable for the purpose for which the record was created.

      To me ‘reliable for the purpose of identifying the person’ = ‘strong identity assurance’.

      My thinking is this: Strong identity proofing processes are where the traditional written signatures come it. When issuing a credential to support follow-on e-signing of high-value (Level 3-type) transactions, the issuer will likely want a usage agreement. These usage agreements — in today’s world — tend to be paper-based and require written signatures. Should the credential be abused, the issuer has a clear legal path they can pursue.

      But this would be a one time collection and thereafter the signing of transactions can be done electronically.


  6. Re point number 52, seems you missed the multi-million dollar Canadian academic research project, On the Identity Trail, headed by Ian Kerr of the University of Ottawa. The ID Trail was made up of over 30 Canadian academic researchers working on identity issues: http://www.idtrail.org

Comments are closed.