Identity Management and Application Integration

Identity management solutions integrate systems, services, and applications into a single ecosystem that provides authentication, access control, enterprise SSO, identity information and the policies related to those identities. While I have dedicated time to explaining how to provide these capabilities to Linux systems - it is now time to broaden the scope and talk a little bit about services and applications.

In some ways, services and applications are very similar. They are both usually

web-based and accessible by browsers and via an HTTP based API. However, there are other services that can (and should) be integrated into the identity management fabric. To name a few I would call out CUPS printing services, IMAP, VPN, and storage servers like NFS and Samba. These services really deserve separate articles, so I suggest you focus primarily on the services that "speak HTTP" and use the term “service” and “application” interchangeably in this context.

Services are written in different languages and use different frameworks - the most common being Java, Python, Ruby and PHP. In addition, Perl-based applications are still popular in some environments. While Java has historically provided a number of tools and capabilities to help solve identity related problems - there were still some gaps in the available open source offerings. While this has changed recently, I will set this topic aside for a future article as Java deserves a separate, more focused post. Here we will talk about web applications that leverage, or can leverage, Apache as a web server.

Traditionally applications have been built using frameworks that provided very basic LDAP capabilities. In the modern world this is not enough any more. It is also very costly to build robust identity management capabilities into every application. The authentication and identity information gathering can be offloaded from an application to a series of Apache modules that provide authentication, enterprise SSO, access control checks, and collect all necessary information from the central LDAP-based server of your choice; this includes Active Directory (AD), IdM/FreeIPA, IdM/FreeIPA in a trust configuration with AD, or a generic LDAP server. Once collected, the information is passed to the actual application in the CGI variables or HTTP header. Applications can simply use this data instead of building in their own LDAP support.

We have been promoting this approach for more than a year now and while we presented on it at a number of different conferences - it is now time to spread the word and to help you reduce your development burden and costs.

The slide deck that covers this approach was published on the Ohio LinuxFest site and is quite comprehensive. This conference was held in October 2015 in Columbus, Ohio. Unfortunately, I was not able to present there. Thunder, rain and humanity turned against me. If you are interested in the details of this unfortunate trip you can take a look at my LinkedIn blog.

Here is the deck. There are other talks on the subject. Some are a bit more technical. This one is a good example. If you are interested in this topic and want to get more information, I encourage you to comment on this post. Feedback and suggestions are always welcome. Remember, we appreciate all contributions and welcome any joint efforts that help to solve real world problems in this area. I look forward to working with you!