IAM Myth: Do-It-Yourself IDM

Yes, it is easy to create a simple script that is run once and copies the data. System administrators do that every day. It is much more difficult to create a script that can be run periodically and updates the data. This script has to check if the target account already exists before creating it (otherwise the logs will be full of error messages all the time). It has to compare if existing account needs to be modified. It has to deal with passwords that usually cannot be compared due to incompatible hashing mechanisms. It has to have a list of exceptions for accounts such as administrator and root. The number of cases that the script must handle grows very quickly. And all of that is usually discovered the hard way: you will find out what to do only after the script destroys half of the data. The size of the code is increasing. It is becoming unreadable and difficult to maintain. It breaks all the time and needs frequent re-testing. It gets very expensive. It can even get more expensive to maintain this script than to do everything manually.

The real killer for Do-It-Yourself approach are security policies in general and roles in particular. The principle of Role-Based Access Control (RBAC) seems to be very easy. And it is. The problem is that the traditional simple static RBAC is just not good enough. It leads to role explosion. There are ways how to improve it …​ but here it stops being static and simple. You will need hierarchical roles, dynamic expressions in roles, parametric roles, time constraints (valid from - valid to) and so on. It takes years to implement this. We know it very well. We have done it.

There is also an alternative way. Maybe we do not need roles at all. There is this fancy ABAC buzzword. Attribute-Based Access Control is a nice and elegant idea. But the problem is that it is designed for access control, not for provisioning. Provisioning systems must pre-set access control instructions long before any access happens. While ABAC relies on many "contextual" attributes that are just not yet available in provisioning scenarios. Therefore the value of ABAC in provisioning is very limited.

But you can use just the principle of ABAC: use an algorithm (e.g. script) instead of roles to determine access permissions. This works well for simple systems. But in complex scenarios the code gets very complicated. I mean extremely complicated. Imagine a code of tens of thousands of lines with many if-then-else statements. Programmers know this very well and they are taught to avoid it. And for a good reason. Such code is unmaintainable. It is a disaster.

Albeit all of the complexities of provisioning it may still be possible to create and maintain a DIY solution for relatively simple solutions. This is especially attractive for smaller telcos and service providers. Almost all the identities are the same, access control rules are simple, it does not change too frequently. But the worst enemy of such solution is the very thing that feeds it: the network. Network is not reliable. Communication errors and time-outs happen all the time. This is usually not a problem when the number of identities is low. Occasional problems can be easily fixed manually if they happen once per month. But this all changes when the number of identities grows. If there is an error every day then it is not feasible to handle that manually. The system administration effort grows. But this is only the tip of the iceberg. Such errors mean that a customer does not have access to the service or someone has an access where he should not. The collateral damage is huge. Therefore the script must be designed to handle all the errors well. This may sound as an easy task but it is not. The number of cases that needs handling multiply very quickly. Script libraries are chronically bad at error handling. Try to look up documentation of your scripting language and try to figure out how to distinguish "already exist" error from a timeout. This is expected: scripting languages are designed for quick prototyping. They are not designed for strict error handling and recovery. And just think about how you are going to test such scenarios. And re-test. And re-test. After every change.

DIY is a good start. It can work for a very simple and very static scenarios. But once the script grows beyond the 100 lines of code it is time to think about a different approach. Get an identity management system. It does not need to be a big expensive system. There is a couple of nice open-source systems to choose from. Open source system has an additional advantage that you can customize it to your exact needs.

If you have a time available to develop an identity management solution then do not start from a scratch. The amount of work required to do it is huge. It is at least ten times more than you currently expect. You will not be able to finish it and your work is very likely to be wasted. Find an existing open source project and join forces. You will get a huge benefit from existing code base which will allow you to start quickly. And you can always modify the code to customize it to your needs - and contribute that back to the community.