SSO

Single Sign-On (SSO) is a solution which lets users authenticate at one application and then use that same user session at many completely different applications without re-authenticating over and over again.

HTTP Cookies (RFC 6265) are vital component to achieve SSO, as it tracks the user’s session across different applications. Before going in detail on SSO, let's look at the HTTP Cookies.

HTTP Cookies 

• An HTTP cookie is a name-value pair data sent by a web-server (party-1) to a web-browser (party-2) to maintain a state between those two parties. 
• Because of state maintenance mechanism, cookies are used for,
• Tracking user's information and browsing patterns: For example: preserving cart items in a shopping website and displaying advertisements based on browsing history .
• User authentication: To know whether the user is logged in or not, and which account they are logged in with. 
• HTTP Cookies (RFC 6265) has defined some attributes associated with cookies: They are:

Attributes	Explanation
Name/ Value	Any US-ASCII characters with some exceptions. For example: SessionID=123
Domain	- If specified, the domain and subdomains of the cookie where this cookie can be sent to. For eg: if Domain=example.com; then browser can send cookie to example.com and host1.example.com as well)  - If not specified, it will be a handled as a host-based cookie and browser only send to the exact domain and not to its subdomains. For eg: from earlier case, the browser can send only to host that which it set the cookie, i.e., to example.com only.
Path	A given URL path where the cookie applies to. For eg: / (i.e., root path)
Expires	GMT timestamp that says when the cookie expire. For eg: 2018-08-24T22:30:17.000Z. If not specified, the cookie is valid until the browser closed.
Max-Age	The amount of time (in seconds) the cookie should be valid. For eg: 3600. Both Expires and Max-Age are used for session timeout and context remains same. If both (Expires and Max-Age) are set, Max-Age will have precedence.
HttpOnly	When used, the cookies aren’t accessible via JavaScript, giving some protection against XSS attacks.
Secure	When used, the cookie can be only transferred through HTTPS, regular HTTP requests won’t include this cookie.
SameSite	Prevents the browser from sending the cookie along with cross-site requests. Provides some protection against cross-site request forgery attacks.Possible values are:  - Strict: Cookie won’t be sent to target site in all cross-domain browsing context.  - Lax: Cookie will be sent along with the GET request initiated by the third-party website, but not request to POST or request originated from iframe, img, and script tags.

• Creating a cookie with same name (value can be anything), and set the Expires property to a date in the past will make that cookie to be removed or cleared-out from the browser and user will lose his/ her session.

How Cookies are related to SSO?

Cookies are the ones controls and tracks the user session in the web-browser and that helps to achieve the SSO across all applications within the same domain. Refer below sequence diagram and its explanations in detail.

SSO Sequence Diagram

Note: All servers are hosted in the same domain example.com.

1. User request page1.html from host1.example.com (Application-1 & Web Agent-1).
2. host1.example.com sees there is no valid Session Cookie.
3. Hence redirect the user to sso.example.com (SSO & Authentication Services) for authentication with return URL as page1.html.
4. Browser request for authentication to Authentication service.
5. Authentication service displays login page for the user to enter their username/ password.
6. User submits username/ password.
7. Authentication service authenticates the submitted credentials.
8. Upon successful authentication, Authentication service sets redirect URL to page1.html (from #3) and SSO service sets the Session Cookie with the following attributes:

• Cookie Attributes	Values	Explanation
  Name/ Value	SessionID=123	This Session Cookie is named as SessionID and value as 123.
  Domain	example.com	This Session Cookie is valid for domain  example.com and all its subdomains like sso.example.com, host1.example.com and host2.example.com.
  Path	/	This Session Cookie applies to path root.
  Expires/ Max-Age	2018-08-24T22:30:17.000Z	This Session Cookie will expire on July 24, 2018 at 10:30PM, GMT.
  HttpOnly	HttpOnly	This Session Cookie is not accessible from   JavaScripts.
  Secure	Secure	This Session Cookie can be sent only in HTTP connections.
  SameSite	Strict	This Session Cookie is not valid for any cross-domain browsing context.

9. Browser redirect to page1.html at host1.example.com with the Session Cookie.
10. host1.example.com asks SSO service to validate the received Session Cookie.
11. SSO service validates and return response to host1.example.com.
12. Finally host1.example.com allows user to access page1.html.
13. After sometime, in the same browser session, the same user with valid Session Cookie request to access page2.html at host2.example.com (Application-2 & Web Agent-2).
14. host2.example.com request SSO service to validate the received Session Cookie.
15. SSO service validates and return response to host2.example.com.
16. Finally host2.example.com allows user to access page2.html without asking to re-login at sso.example.com.
• This is because the Session Cookie is bound and valid to domain example.com, and hence SSO & Authentication Services did not authenticate the user once again.

Conclusion

• So far we saw SSO works fine across applications when their domain name is same (i.e., sso.example.com, host1.example.com and host2.example.com, all are based on same domain example.com).
• But what happen if applications running on different domains? For example: sso.example.com, host1.example1.com, host2.example2.com. How to achieve SSO for these applications?
• The answer is Cross Domain Single Sign-On (CDSSO).
• Let’s discuss about CDSSO in next blog post. At least this blog gives some basic concepts on SSO and let's look in the next post for complex use-cases on CDSSO.

Lightweight Directory Access Protocol (LDAP)

Before going into the LDAP, we have to look into what are Directory Services and X500 Model.

Directory Service

• Directory Service can be characterized as a hierarchical tree-based naming system that offers numerous distributed system advantages:
• Unique names can be determined by concatenating hierarchical naming components starting at a root node (e.g., "com")
• Object-oriented schema and data model supports very fast search operations (uses Key-based querying).
• Due named sub-tree partitions, the features like Distribution, Replication and Delegated or Autonomous Administration are supported.
• Supports Authentication and Fine-Grained Access Control mechanisms.
• Few examples of directories are DNS, NOS, Novell's NDS, Microsoft's Active Directory.
• Directories are designed and optimized for more READ/ SEARCH operations, than WRITE/ UPDATE operations.
• In real world example, a telephone directory is a directory system that contains a list of subscribers with an address and a phone number in a dictionary format, than in a tree-based fashion.

Telephone Directory

X500 Model

• X.500 is a series of computer networking naming standards and models for Directory Service.
• The primary concept of X.500 is that there is a single Directory Information Tree (DIT), a hierarchical organization of Entries and these can be called using:

• Distinguished Name (DN) is a unique Distinguished Name. Much like a "path" to a filename in a file system.

• For eg: cn=alice, ou=People, dc=example.com

• Relative Distinguished Name (RDN) is a component of the distinguished name. Much like a "filename" in a file system.

• For eg: cn=alice, ou=People is a RDN relative to the root RDN  dc=example.com

Directory Information Tree (DIT)

• DNs are also called as naming contexts, because it describes the namespace where the entry lives.
• X500 Model suggest the way how directory service can be designed in a DIT to have a database to fetch information for a given entry. 
• Directory Access Protocol (DAP) is one of the protocol defined in X.500 that says how to access the entries in the DIT on TCP/IP stack.

LDAP

• The Lightweight Directory Access Protocol (LDAP) is an open, vendor-neutral, industry standard Application Layer protocol interface for accessing and maintaining distributed directory information services over an Internet Protocol (IP) network.
• The latest specification is Version 3, published as RFC 4511.
• LDAP is based on:
• A simpler subset of standards within X.500 model, hence sometimes LDAP is called as X.500-lite.
• DAP to access X500 model directory, hence it is called as Lightweight DAP.

Naming Model

• An Attribute defines as a piece of information that the directory entries contain. 
• Attribute is similar to DB column name.
• The most widely used naming attributes are defined in the following table:

Attr.	Abbreviations	Explanations	Examples
dc	domainComponent	An element of a DNS domain name	dc=acme,dc=com
uid	userid	A person's account name	uid=jdoe
cn	commonName	Full name of a person, group, device, etc.	cn=John Doe
l	localityName	Name of a geographic region	l=Bay Area
st	stateOrProvinceName	State or Province	st=CA
o	organizationName	Organization name	o=Acme
ou	organizationalUnitName	Organization unit name	ou=Sales
c	countryName	Two letter country code	c=US

Schema Model

• An LDAP schema is a set of rules that define what can be stored as entries in a LDAP directory. 
• We have similar concept in RDBMS, where DB schema contains information about database structure, tables, columns, data types and constraints.
• The schema model consists of two types of elements: 
• Object Classes: 
• Defines as a placeholder for attributes. 
• Similar to DB tables.
• Object classes come in one of three kinds: 

Abstract	Structural	Auxiliary
Defines an attribute or set of attributes that all object classes in an object class structure inherit. Every object class structure must have an abstract object class as the top-level object class.	Defines an object entry type. Every entry must contain at least one structural object class. A structural object class inherits either from top or from another structural object class.	An auxiliary object class adds attributes to another object class. Useful to define a set of attributes used by multiple object classes.
There are only two abstract classes: The top class is present in every entry, and it requires the objectClass attribute be present. The alias requires the aliasedObjectName attribute be present.	For example:  Object classes such as: organization, person,  organizationalPerson  or device.	For example: Object class strongAuthenticationUser  allows the attribute userCertificate;binary  be present, but this class could be used in an entry with object class person, device or some other structural class.

Object Classes in a Class Diagram

• Attribute Types: 
• Defines the data types of attribute values. 
• Similar to DB column's data types.
• Attribute Type Definition specifies:

Syntax	Matching Rules
Defines the data format in which an attribute value is stored.	A matching rule encapsulates a set of logic that may be used to perform some kind of matching operation against two LDAP values
For example: Directory String, Integer, and JPEG are examples of standard LDAP syntaxes.	For example: Comparison, Sort and Order

Protocol Overview

• A client starts an LDAP session by connecting to an LDAP server, called a Directory System Agent (DSA), by default on TCP and UDP port 389, or on port 636 for LDAPS. 
• The client may request the following LDAP operations:

Operations	Explanations
StartTLS	Use the LDAPv3-TLS connection
Bind	Authenticate and specify LDAP protocol version
Search	Search for and/or retrieve directory entries
Compare	Test if a named entry contains a given attribute value
Add	Add a new entry
Delete	Delete an entry
Modify	Modify an entry
Modify Distinguished Name (DN)	Move or rename an entry
Abandon	Abort a previous request
Extended Operation	Generic operation used to define other operations
Unbind	Close and exit the connection

LDIF

• LDAP Data Interchange Format (LDIF) is a standard text-based representation for LDAP data.
• LDIF conveys directory content as a set of records, one record for each entry.
• It also represents update requests, such as Add, Modify, Delete, and Rename, as a set of records, one record for each update request.
• This is an example of a simple directory entry with several attributes, represented as a record in LDIF:

dn: cn=John Doe,dc=example,dc=com

cn: John Doe

givenName: John

sn: Doe

telephoneNumber: +1 800 800 8888

telephoneNumber: +1 800 800 9999

mail: jdoe@example.com

manager: cn=Eliza Beth,dc=example,dc=com

objectClass: inetOrgPerson

objectClass: organizationalPerson

objectClass: person

objectClass: top

Other Useful Notes

• In LDAP 3.0, there is a special root called rootDSE (where DSE stands for “DSA-specific entry”) is defined as the root of the DIT server. 
• The purpose of the rootDSE is to provide data about the directory server itself.
• i.e., rootDSE is not part of any namespace, but it contains namingContexts, which provides a list of all DNs in the the DIT.
• Directory servers publish internal schema as an entry in the directory. 
• It can be retrieved by LDAP clients performing a baseObject search on the a special entry that is defined by the directory server to publish schema information (e.g., cn=schema), with the attributes attributeTypes and objectClasses specified as part of the search criteria.
• Each LDAP directory has some default schema, which developers can customize, or "extend," by adding elements to it. 

Differences between LDAP and Active Directory

• Both are related to Directory Service, which is a software system service that stores, organizes and provides access to information in a system's directory. Typical real world example is a telephone directory, where we lookup the telephone number by referring to alphabetical names.
• LDAP is an open, vendor-neutral industry standard and application-layer protocol, that provides a mechanism (a way) to connect, search, and modify information in a system's directory. As such a directory system must exist to access the information via LDAP.
• Active Directory (AD) is a proprietary directory software by Microsoft, and it supports LDAP and along with broad range of directory-based identity-related services (like authentication, authorization, policy management, etc.,)

Difference between DOM and SAX

• Both are XML parser, that process the XML document to breaks up the text (element) into small identifiable pieces and which are finally mapped to Objects for application to process the elements.
• Document Object Model (DOM) processes the entire document and stores the object in a tree structure to manipulate.
• Simple API for XML (SAX) processes the document as it being read (like streams), generate events based on tags and events are handled by the event handler.

DOM: A tree-based processing

DOM processes the XML document and loads the data into memory in a tree-like structure. Consider the following XML code snippet:

1. <?xml version="1.0"?>
2. <users>
3.   <user ID=”1”>
4.     <fname>John</fname>
5.     <lname>Doe</lname>
6.     <email>jdoe@force.com</email>
7.   </user>
8. </users>

A DOM processor analyzing this code snippet would generate the following tree structure in the memory.

SAX: An event-based processing

SAX analyzes an XML stream as it goes by. The above example document generates the following events:

1. Start document
2. Start element (users)
3. Characters (white space)
4. Start element (user) with Attribute (ID="1")
5. Characters (white space)
6. Start element (fname)
7. Characters (John)
8. End element (fname)
9. Characters (white space)
10. Start element (lname)
11. Characters (Doe)
12. End element (lname)
13. Characters (white space)
14. Start element (email)
15. Characters (jdoe@force.com)
16. End element (email)
17. Characters (white space)
18. End element (user)
19. End element (users)

The SAX API allows a developer to capture these events and act on them.

Pros and Cons

DOM

The tree is persistent in memory; it can be modified so an application can make changes to the data and the structure. It can also work its way up and down the tree at any time.

DOM can also be much simpler to use.

On the other hand, a lot of overhead is involved in building these trees in memory. It's not unusual for large files to completely overrun a system's capacity. 

In addition, creating a DOM tree can be a very slow process.

SAX

Analysis can get started immediately, rather than waiting for all of the data to be processed, hence fast processing.

Application is simply examining the data as it goes by, it doesn't need to store it in memory, hence cost less resource.

Application doesn't even have to parse the entire document; it can stop when certain criteria have been satisfied, hence efficient processing.

On the other hand, the application is not persisting the data in any way, it is impossible to make changes to it using SAX, or to move backwards in the data stream.

DOM	SAX
Slow processing	Fast processing
Cost more resource	Cost less resource
Inefficient processing	Efficient processing
Non persistent	Persistent

When to choose DOM and SAX?

Depending on following factors, we can choose DOM or SAX,

Application purpose
If application needs to refer back to processed data, make changes to the data and output it as XML, then DOM is a choice. Still SAX can be used, but the process is complex, as the application has to make changes to a copy of the data rather than the original data itself.

XML data size
For large files, SAX is a better choice, since it processes the XML data as streams.

Need for speed
SAX implementations are normally faster than DOM implementations.

SAX and DOM are two implementations of parsing XML data, so we can use DOM to create stream of SAX events, and SAX to create a DOM tree.