Part I - Implementing Single Sign On for ERP Applications
I worked on multiple Single Sign On Implementation projects during my experience with Hexaware. Just to let you know, I am currently working on one such project. I am planning to consolidate all the Single Sign On Technologies available with various vendors and provide my personal analysis here and also how organizations can deploy these solutions in their enterprise. Also, I want to provide details about my personal experience with different SSO projects.
My previous years of Single Sign On or LDAP related experience include the following implementations:
- UNIX Single Sign On with pam_ldap and nss_ldap
- Creating an Enterprise Directory for Humar Resources Management with Sun Iplanet Directory Server
- Peoplesoft Single Sign On with Siteminder Policy Server
- Oracle EBS Single Sign On with Oracle Identity Management and WNA
I am planning to write more about these three implementations that I did during my previous years of Single Sign On or LDAP related experience. Also, I always wanted to write here about various SSO solutions available with different vendors. Also, I want to let you know how SSO and LDAP Directories are related and complimentary in these implementations. All of these items are not possible to explain in one single article, so I will be writing mutiple blogs about the same.
I want to write about the SSO implementation with Unix first. Though this does not involve any ERP products, this (unix and SSO) was my first SSO project and I wanted to write about it.
In one of our customer site, they had around 110 Unix servers, predominantly HP Unix servers, along with some servers running Linux Operating Systems. They kept all their Unix User information locally on the /etc/password file and managed seperately using native UNIX user and group administration tools such as, useradd, usermod, userdel, groupadd, groupmod and groupdel. They wanted to centralize the user information database in Active Directory. (What a weird combination – UNIX users on Active Directory?).
We successfully completed a POC for this. For this authentication to work, there are few components involved. PAM and NSS along with Active Directory and Kerberos on the Windows Domain Controller side.
PAM is Pluggable Authentication Module that provides a mechanism for authentication plugins. NSS is NetworkService Switch Plugin used for authenticating against the LDAP server. HP has a free product called LDAP-UX which includes components such as pam_ldap and nss_ldap which are necessary for LDAP Integration.
In UNIX Environment, Single Sign On was provided for authentication – using the PAM Plugin, in general. When a user enters his username and password, the password credentials are verified againt Kerberos and Active Directory. Once authentication is successful, the user is allowed to enter to the UNIX prompt. The Unix Users are Groups information can also be stores in Active Directory. However, this poses issues since Active Directory is not really meant for storing UNIX User and Group information because it was build for Windows machines primarily. However it is possible to integrate Active Directory with UNIX logins.
For Peoplesoft, Single Sign On implementation is different than how it works in the UNIX Environments because they use different ways. However, you can easily coorelate the same steps involved (first step is authentication, and then authorization).
Authentication involves checking user credentials to make sure they are correct. For example, UNIX login checks the login and password in Kerberos and Active Directory. Authorization involves what a user can do on the system. Authorization comes after authentication. Once a user is authenticated, the system (lets say Peoplesoft) will check what are the “things” the user is authorized to do.
Lets talk more about these in coming days.