Identity Management: Avoid Vendor Lock-in

Since being asked to help out with implementing a new IGA tool many months ago I have come to accept one thing: No IGA tool can handle all of your complex business logic/rules out of the box. This shouldn’t be new news to anyone that has been in IT longer than a year. If you are believing your vendor that they are different and they can in fact do everything you are an idiot.

The tool that my group was asked to implement was extremely bad. In summary it simply didn’t work. It’s not really important what the tool was at this point.

The requirements are still the same….make something work!

Every vendor in the world when asked about a feature their tool/solution doesn’t support will simply say “you can write a script for that”. That’s true but when your vendor says you need to write scripts for everything it’s time to take a step back and rethink things.

What am I trying to achieve? Fully automate Joiner/Mover/Leaver activities in regards to Identity Management. 

Joiner: The generic term used to represent all of the things someone does when a new person joins your company. Create the needed accounts, provision access to systems etc.

Mover: The generic term used to represent all of the steps needed to take place when someone changes positions in your company. Remove access to the old systems and provide new access to the new systems.

Leaver: The generic team used to represent the work you do when someone leaves your company for various reasons. Disable the accounts and eventually delete them. Ensure all applications that had local accounts have been addressed etc.

Every company will have different processes so that is ultimately why it’s impossible to create a product that can address any business logic you may have. If you find a solution that has the necessary functionality to handle your needs you will be so tightly integrated with that solution if you ever have to migrate to something else because of licensing or acquisitions it will be almost impossible….until now.

What my group is implementing is micro services that are hosted in Amazon Web Services (AWS). 

Let’s get on the same page with a few things….what is automation? A piece of code that executes the same every single time and replaces a task that a human used to have to do. What about pieces of work with many tasks? Now that is orchestration. Orchestration is when we chain many pieces of automation together to complete an even bigger piece of work….in my case it would be the pieces of work that represent Joiner, Mover and Leaver.

I use AWS Lambda functions for the individual pieces of automation and I use AWS Step Functions to handle the orchestration piece. When drawing out all of your steps try and keep your Lambda functions as small as possible. 

Example: You will have logic to determine what a user account logon id (naming standard?) should be on your domain and you will have code to create a new user….these should be separate Lambda functions. If the rules to change how we determine a user id ever changes we only need to update one small piece of code.
Okay Shawn….what about staffing? I prefer to buy a tool so I can get support from a vendor. My people aren’t developers….they are whatever you call someone who does shit manually. <this isn’t actually what was said but it is what I heard> The people you have either need to adapt their skillsets or you need new people. Yes it’s that easy. Finding experienced staff to support a huge monolithic tool isn’t easy to do and if you do find someone they are expensive. BUT finding python developers from your local community college isn’t as difficult. Yes they will need some experienced leaders to work with but I believe this new approach you can simplify the requirements for your organization in regards to staffing. If you don’t have great technical leaders you are not ready for this change.

Remember we are trying to do things different. Last week I was in Las Vegas at the Gartner IAM conference and doing things different was a major theme. Another theme was using machine learning….if you are going to depend on a vendor to build this you are making a mistake. Every cloud vendor has a ML micro service and that is where you need to start creating models and importing data. That’s the only way you know your recommendations aren’t influenced by the vendors. 

What’s another benefit of adapting this approach? All of your code and processes can be part of a DevOps toolchain. Every piece of configuration can be part of your source control which can be put through an intensive automated testing prior to ever going to production.  All IGA tools today can be changed by the administrator of the tool and every one of them have the ability to not track changes. Your company may have strict rules but none of that matters in the real world. If you think changes don’t go in without going through your change control process you are disconnected from reality. By implementing a DevOps process for your identity no changes can be made so your solution has never been more audible and ready for compliance.

Fulfillment is all we are talking about here….if your processes require business rules that are hard please keep them out of the IGA tool. If you do this you will eliminate the vendor lock in and you can stay flexible if you ever need to change later. 

Identity Management: Avoid Vendor Lock-in Identity Management: Avoid Vendor Lock-in Reviewed by Shawn on 4:56 PM Rating: 5

No comments:

Powered by Blogger.