Motivation
AMX has been designed and developed by me Philip Nesfield and is the result of more than 10 years consulting experience in identity management and access control. My experience over the years has been using most of the major IdM suites, BMC Identity Manager, SUN Identity Manager, a little Oracle and a lot of Microsoft FIM. I started by supporting and managing a large (~5,000) user SUN Idm system for Agilent Technologies in 2001, which managed accounts in Siebel CRM, Oracle ERM and 3 other smaller applications. The system was complex, privileges were subject to separation of duties analysis, multi-level approval and was written in SUN’s XPRESS language and Java.
The main support issues were speed, and difficulties for approvers in using the system. Users were sent emails telling them that they had a task to attend to in the Idm system such as approving a new user, and rather than using the Idm application they would reply to the email saying “approved”. Nice try, the Idm system was not checking its emails, but obviously it should have been.
There was so much application code that product patches always ran into problems and needed massive amounts of testing. From this I learnt, don’t customise an Idm system too much. If it doesn’t do what you want, either don’t buy it or change your processes. If you do extensive customisation, the exorbitant purchase cost will pale into insignificance when compared with the cost of maintenance. After about 5 years of use and new product versions which were too expensive to implement, we were stuck on a version that went out of support. At that point I had had left the company, but I heard it was cost effective to re-write everything in Oracle Idm (Thor), rather than to upgrade to version 7.1. This was lucky because SUN Idm was deprecated when Oracle bought SUN in 2010.
I moved on to a consulting position with DNS and later SecureWorks which is now part of Dell. This gave me a much wider experience of identity management systems, and because of the travel, plenty of time to work on AMX . During this period I was involved in another slow motion train crash involving SUN Idm. This was a very large user base with very complex approval workflows. At this point writing XPRESS had moved from a text editor to Netbeans, which allowed a visualisation of the workflows. Ever since this experience I have used this flow diagram of the main module as a caveat against over complicating identity management by trying to apply too much logic to an approval workflow and creating a testing and support nightmare.
complexity
The common thread was testing and release to production. Testing web applications is horribly manual and non-repeatable, tools like Selenium can only work when the application is stable . The production test systems in my experience never found all the problems encountered in the real (production) world. The AMX tools were originally developed to help the release to production process and over the years it became self evident that a robust set of adapters linked to an HR system is a simple and pragmatic approach to baseline IAM.
I think Identity Management should be left to the HR department, and then account management only involves propagating the identities to the resources in the form of accounts. For example if HR says you are in customer services, you should simply get access to all the customer services resources. This is of course too simplistic for all business processes, but it does help with the simple situations that auditors annoyingly pick up on. Situations like leavers still having active accounts on systems, and separation of duties faults, both are eliminated by AMX’s approach.
I found that leaving Identity Management to HR, does have some risks too, so AMX has trip wires. If more than a configurable number of persons leave the organisation, say 5%, AMX will process none of them. I have been seen two situations where this happened. In one Operations converted a large number of manufacturing staff to contractors working for an outsourcing organisation. IT were not informed nor involved but HR were, a trip wire would have stopped their accounts being disabled while the identities were moved to the new organisation’s systems. In another situation 5,000 staff were end-dated in the HR database by accident during an upgrade of the HR system, a tripwire would make the Account Management system the first system to report it, and it could be fixed before the payroll run. Interestingly it is always a big management issue if users are unable to login or work, a bigger deal than if they aren’t paid. A trip wire can also stop an update when the HR unilaterally changes a role name from salesman to salesperson for political correctness, which would cause all the salespersons have their roles blanked an unable to access their network shares.
AMX is reversible, it keeps transaction logs. It also has a dry-run (information only mode). This was implemented because of lessons learned from bitter experience during a release to production of a BMC IdM system. Identity management systems use highly privileged accounts, and given half a chance “take control” of resources making inappropriate changes, for example converting full names to lower case, or blanking phone numbers in the Active Directory. This causes a network storm, slowing everything to a crawl. Doing a dry-run avoids any surprises when you turn the IdM system on.
The motivation for creating and publishing these tools is to make something useful and have people benefit from it. I am always hopeful that some consulting might generate some income, contact me if you would like that. Otherwise, enjoy!