1. Overview
This document will explain about The Lightweight Directory Access Protocol which is one of the main authentication protocols developed for directory services and Single Sign-On which is an authentication method which enables users to securely authenticate to multiple applications and websites just by using one set of credentials.
2. Technologies and Tools Used
The following technologies has been used to achieve the same.
- Lightweight Directory Access Protocol
- Directory services
- Single Sign-On
3. Use Case
Lightweight Directory Access Protocol:
Consider a scenario where an organization needs to enable authentication to IT resources such as an application or server. They would be pointed to the LDAP database, which needs to validate whether the user would have access to it or not. That validation should be done after passing a user’s credentials.
Single Sign-On
Consider the same scenario where an organization needs an authentication method that enables users to securely authenticate with multiple applications and websites by using just one set of credentials.
4. Architecture
Lightweight Directory Access Protocol:
LDAP authentication follows the client/server model in which the client is generally an LDAP-ready system or application that is requesting information from an associated LDAP database and the server which is the LDAP server.
The server side of LDAP is a database that has a flexible schema. In other words, not only can LDAP store username and password information, but it can also store a variety of attributes including address, telephone number, group associations, and more. As a result, a common LDAP use case is to store core user identities. By following this, the IT can point LDAP-enabled systems and applications to an associated LDAP directory database, which acts as the source of truth for authenticating user access.
How LDAP Works:
The client sends a request for information stored within an LDAP database along with the user’s credentials to the LDAP server. The LDAP server then authenticates the credentials submitted by the user against their core user identity which is stored in the LDAP database.
If the credentials submitted by the user match the credentials associated with the core user identity that is stored within the LDAP database,the client is granted access and receives the requested information (attributes, group memberships, or other data). If the credentials sent don’t match, the client is denied access to the LDAP database.
Single Sign-On (SSO)
SSO works based upon a trust relationship that is set up between an application, known as the service provider, and an identity provider. This trust relationship is based upon the certificate that is exchanged between the identity provider and the service provider.This certificate can be used to sign identity information that is being sent from the identity provider to the service provider so that the service provider knows it is coming from a trusted source. In SSO, this identity data takes the form of tokens which contain identifying bits of information about the user like a user’s email address or a username.
The login flow will follow the below path:
1.A user browses to the application or website they want access to, aka, the Service Provider.
2.The Service Provider sends a token that contains some information about the user, like their email address, to the SSO system, aka, the Identity Provider, as part of a request to authenticate the user.
3.The Identity Provider first checks to see whether the user has already been authenticated, in which case it will grant the user access to the Service Provider application and skip to step 5.
4.If the user hasn’t logged in, they will be prompted to do so by providing the credentials required by the Identity Provider. This could simply be a username and password or it might include some other form of authentication like a One-Time Password (OTP).
5.Once the Identity Provider validates the credentials provided, it will send a token back to the Service Provider confirming a successful authentication.
6.This token is passed through the user’s browser to the Service Provider.
7.The token that is received by the Service Provider is validated according to the trust relationship that was set up between the Service Provider and the Identity Provider during the initial configuration.
8.The user is granted access to the Service Provider.
5. Screen Shot
Login Page:
Confirming the Identity:
Soft Tokens for Validation Process:
