The Future is Digital
Becoming digital is the surest way for you to understand your customers' needs and meet their expectations. Learn how Perficient can help anticipate what's ahead for you and your customer with a digital strategy centered around empathy, alignment, and agility.
It was back in 2011 when the need was great to develop a directory-enabled web application for internal users with a Single Sign On (SSO) facility. With SSO, an end user does not need to enter credentials specific to an application, instead their computer login / Active Directory domain login is the one used for application log-in. For corporate networks, SSO is available as a default wherever Active Directory integrated applications (e.g. Microsoft Exchange) are deployed.
This was a unique requirement for a web application, which was different from other internal applications already developed.
Requirement:
In working with a client on a project, one of the requirements was for the web application to be directory-enabled and capable to present a customized home page and menu for a logged-in user, depending upon specific properties associated with that user ID. If a user is a manager, and belongs to a different operations group within a department, and if they open the web application, they should get authorizations, and options in the application to perform the tasks for their role. Some properties of a User ID are: Manager Code, Employee Type, Employee ID Or Operations Group, etc.
Challenges:
Since Active Directory was to be used for user authentication and SSO, the properties that were expected to maintain for the end user’s ID were not available. Upon analysis, we found that even if we use the unused attributes of a user object in Active Directory, we were not able to fulfill the requirement, since the value string was not matching for certain objects, and there were other attributes which specifically needed to be created.
It was not feasible to create non-standard attributes of a user object in Active Directory since having those attributes associated with user objects required modification to the schema of Active Directory. Having these modifications to the schema of Active Directory for a single web application was not justifiable, and this was out of scope of the actual project work.
Solution:
Since modifying the schema of Active Directory for the creation of custom attributes was not feasible, we started looking for a solution of an alternate directory service. Other groups within our team verified that the end user authentication and application queries for user properties can be separated through the application. Once we confirmed that the application could be configured to have two directory services – one for authentication and one for querying the user properties – we moved on with a directory service that can have custom attributes as required for the application.
The solution we used was Active Directory Application Mode (ADAM). ADAM is a mode of Active Directory, which can be used for directory-enabled applications. With features of Active Directory designed for requirements such as ours, ADAM was a good fit for this application development. It does not have administrative overhead like Active Directory; however it is a lightweight directory access protocol directory service that contains many components and features of Active Directory. The major benefit of using ADAM over Active Directory for directory-enabled applications is that it can be installed on any member server and runs as a windows service. You can have multiple instances of ADAM created on single server. It also facilitates replication of an instance.
We created a test setup and used Active Directory Application Mode (ADAM) to address the requirement of custom attributes like Manager Code, Employee Type, Employee ID, or Operations Group, etc. to be associated with user objects. The steps included creation of an application partition, defining LDAP and SSL ports, instance name and service account.
In a test ADAM instance setup, we created identical users, as that of Active Directory. We added the custom attributes to the user objects in ADAM as per the requirement for initial testing of the web application. We were successful in ensuring that the authentication of the end users was done through Active Directory and the queries related to the properties of logged-in users were answered by the ADAM instance. We were able to render the web pages and menu, depending upon the properties of the end users ID in ADAM.
Since we achieved the expected results, we moved ahead implementing it in production.
ADAM indeed helped us clearing one of the major requirements of this project – and it was a great learning experience!
