Implementing Identity & Access Management

Of the many systems that exist in the current environment, Identity and Access Management (IAM) is perhaps one of the most complex single system —on the basis of sheer number of components that need to talk to each other. Add to it the complexity of integration of legacy system —and you have an almost un-winnable situation. Little wonder, that very few large corporations, have been able to put up a robust, scalable, comprehensive and manageable solution. The key to overcome this hump, is to keep the access definition clear and crisp. Identify which applications you would want to integrate into the system and identify where your current user database are. With this information on hand, you can begin to structure an overall design.

Any identity management environment, will contain the following sections: integration, database/directory servers, extensions that may be required for your environment, applications that need to connect/authenticate against your directory services and last but not the least, administrative and management functionality — like user management, self-service portals.

Take the partial whole, or parts to make whole.

Now there are many ways to build your overall system — especially when it comes to deciding, if you want to take a pre-integrated solution off the shelf, or to build the entire system all over again. An additional complexity creeps in when you build the complete system from scratch. You can choose solutions which bundle one or more than one section into one application suite, or build modularly component by component.

Check out the box, to see the complete suites available both in commercial as well as in open source space.

We are giving here the most granular design and have selected the best of the breed applications from the open source community for each section. Needless to say, these are not the only applications/suites in open source that solve this problem. There are many others that fit the bill too, and you will need to make that judicious call, based on your specific needs.

Integrating existing applications

Here, you need to do a due diligence of the ability of the current applications. If the application in question cannot support external (to the application) userbase and authentication mechanism —for the time being we need to keep them out of the purview of this article. Some of the applications/situation can authenticate against an external directory server, but that may be limited to a few select ones. While still others may be able to directly connect to your central server directly. For our purpose, we will assume that your application can authenticate against any of the following types of databases — LDAP, Windows Active Directory, RDB database servers, radius server, public address books —such as Bigfoot, Google, Yahoo, etc (yes, you can actually design your enterprise architecture to be able to use Yahoo base as the common user base.)

Directory services

Our core solution is built around the LDAP server, while other directory service components are optional and depend largely on your applications that need to be integrated.

At this stage, you will need to be clear, which existing directory servers, you will be able to completely replace (based on the applications capability) and which you will need to keep for the existence of the specific application. In our case, we have assumed that we will need to maintain

Click on the image to enlarge

Most of the LDAP servers come with core functionality of connecting to multiple databases, Mult-master replication (updating simultaneously more than one directories), synchronization ability with Windows active directories, strong access management and a capability to scale to millions of transactions per hour.

As is the case always, we are presented with many options that we can choose from;

Directory service extensions

This section talks about the extensions that you can apply to your solution to upgrade the same for special requirements. For example, integration with Linux Domain Controller (SAMBA). As you may be aware, RBI recently made it mandatory for all financial transactions to use a 2 factor authentication for the transaction to be completed. For each transaction to complete, it is expected that the end user enters a one time password to identify at 2nd level. Using LinOTP you can achieve just that for ANY of the applications/modules that you are running on your infrastructure and compatible with our proposed solution. With SMS gateway integration, passwords are sent using SMS or conventional email system.

Access section

This demonstrates a plethora of access devices that need to connect to your network, at different levels — network access for VPN/mobile users, application level access, web based applications, or OS level access. We have provided a framework, that will allow your devices to connect at all the potential levels.

Click on the image to enlarge

Administration/Audit/Logs

One of the key requirements of a robust IAM systems is a sound systems management system. This is an area, where open source scores and one can add many more modules than the basic one.

The solution presented here are of generic nature and are the building blocks for your requirements. This article should be used as a starting point specific sections may need to be tweaked as per your requirement. As you can, see, you will have a plethora of options to choose from the open source world in this space.