Application Security foundation — LDAP and SAML

In my last story — Quick Guide on Core of Application Security — Authentication & Authorisation, I’ve given a quick introduction on Authentication and Authorization. How does it actually work in the real-life application? This story could provide a quick and hopefully comprehensive view on how the backend application security works.

Starting with a very high level security architecture to introduce some common jargons used in the industry.

End Users: Actual user accessing the applications

User Agent: ‘Browser’ which redirects the requests to different components

Service Provider: Application / backend system

Application datastore: Application level data

Identity Provider (“IdP”): Process of controlling the user’s identity (E.g. Active Directory)

Identity Datastore: User’s identity data (e.g. Emails, credentials, names)

With this basic understanding, we will move one step forward with the classic application security model — LDAP (“Lightweight Directory Access Protocol”). Microsoft Active Directory (“AD”) is one of the best example of LDAP that most companies are using.

Key characteristics of LDAP are,

1. LDAP Identity Provider and Application are in Same Data Center
2. Identities are captured in the LDAP datastore (Microsoft AD) using LDAP protocol (TCP)
3. Authentication is done by LDAP; Authorization is done by Application

Key pain points for LDAP are,

1. External users outside the companies can’t be easily added into the LDAP datastore
2. Applications in different data centers can’t request the LDAP identity provider
3. Sending user credentials to an Application

With the cloud computing (e.g. Azure, AWS) trend, it’s very difficult for an enterprise to maintain the applications in single data center. To overcome the applications and identify providers are in different data centers, SAML(“Security Assertion Markup Language”) is being created and widely used. SAML is also well-known as SSO (“Single Sign-On”)

Key characteristics of SAML are,

1. Applications communicating across data centers (using HTTP Redirect request)
2. Using SSO to avoid entering the user credentials (e.g. Password)
3. ‘Trust’ needs to be established between SAML Identity Provider and Service Provider
4. Authentication is done by SAML (e.g. Active Directory Federation Services— ADFS); Authorization is done by Application using LDAP group

Key pain points for SAML are,

1. The design can’t fit with microservices using REST API (the difficulties in setting up the trust between App services and Identify provider)
2. System-to-system authentication with scheduled tasks without user involved

With the above pain points, OAuth2.0 is being introduced for the modern application design with REST API, cloud services and Microservices.

In my next story, we will further deep-dive into the OAuth 2.0 foundations.

Learn more on Authorization & Authentication

Quick Guide on Core of Application Security — Authentication & Authorisation

Most popular modern authorization framework OAuth2.0 — understanding how it works in 6 minutes