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.)
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
- Windows active directory
- RDB database server, which some of your application use to store user information.
- LDAP – we are assuming some applications will directly authenticate against this
- RADIUS – some of the devices, like Wi-Fi services, mobile access to VPN server, Routers, etc can only connect via a RADIUS server, so we get that into picture too.
- Some of our Linux servers/desktops and Unix servers –can authenticate using a simplistic PAM – pluggable authentication module and we will assume that all our server system can connect using this or any above described methods.
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;
- Open Ldap is one of the most popular core versions in use today. It has the ability to store its backend data as a flat text file or even into a database like MySQL. You can use the stand alone server version of OpenLDAP – slapd or use the complete package, that provides some level of tools to configure your LDAP database. In most cases, you should be good, to select this package, albeit a bit of vanilla.
- Redhat promoted directory server is an equally good option to be used. More popularly known as 389 Directory server. It comes bundled with some of the specific components. However, for most installations you can safely use one or the other.
- OpenDS holds about 40% of the current market space in the directory services and claims to have more than 4 billion user entries worldwide. It is a ground up rewrite and is in 100% in Java. Be careful to check the license terms, especially for developers of solutions
- LSC – LDAP Synchronization Connector: This is your choice, when your decision is going to be based on connectivity with other databases. The package is built on top of Open LDAP, but focuses around wide connectivity of directory services.
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.
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.
- Using FreeRadius, you can allow your mobile users to connect into your network, using the same id and password that they use on your intranet. This is also true for devices like Wi-Fi, printers, fixed attendance machines, IP phones, camera networks, etc. (in case, any one of them needs to authenticate itself on the network)
- The OS level ids, especially in the Unix world, are generally compatible with something known as Pluggable Authentication Module (PAM). PAM allows the system to be configured to use LDAP (amongst many other types) as authentication module.
- Your legacy web applications, will need to learn to NOT use their databases but, to use another one. In case, they cannot make this change, the only way around this would be to use LSC type of module and connect your LDAP to that database server. It is pertinent to note however, such workarounds will not provide you with complete profile or role information.
- The newer portal applications, specially those built on modern content management systems like Drupal (or even Joomla/Mambo) have an inbuilt ability to integrate with LDAP server. Drupal also has the unique distinction to have an out of the box module that allows it to use/integrate OpenID service.
Click on the image to enlarge
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.
- User provisioning/management: Explained in the above section, we recommend usage of Drupal to allow the provisioning ability. It has a simplistic, but comprehensively access controlled method of user management. Specially with the abstracting of the content management, an user: Even without the knowledge of the LDAP working, can easily operate the system. It also offers, some pre-built routines, on self-service for password management, amongst many more things.
- Audit/review and log management: Awstat is a fully functional multi-format aware reporting and log analysis client, which can assist you to solve many challenges at once. Some of the Java components listed below are another source for some of these specific asks.
- Single-point-system-wide management ability: With so many sub-systems working together, one needs a single window solution. In comes Webmin, another open source project that when plugged into IAM solution brings a host of functionality to manage multiple resources.
- General: There are a whole list of software available, in addition to the ones we have listed, that may help you fulfill one of the other needs. A comprehensive list of LDAP software may be found here. http://tinyurl.com/2smhhh. Another location to search, specially for java components for IAM would be http://tinyurl.com/4sq8pgy
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.