Single-Sign-On using SAML

Overview

In a simple standalone web application, user authentication is implemented locally. This means the web application by itself is fully responsible for managing, validating and enforcing authentication. However in an enterprise setup where users need to work across multiple applications often from diverse vendors, this simple approach will be cumbersome. If each of the applications have their own list of user credentials, with possibly different usernames and passwords, users will have to remember multiple usernames and passwords and/or provide these credentials multiple times to get their work done using different applications.

Federated authentication solves this problem elegantly through SSO (Single-Sign-On) by managing the authentication credentials centrally and allowing individual applications to do delegate user authentication to the federation server without duplicating the authentication implementation and management. Also the user is saved from the overhead of entering authentication credentials more than once.

SAML (Security Assertion Markup Language) is a set of specifications that enable federated security (including authentication).

SAML Concepts

Identity provider (IDP): A central system responsible for managing and verifying user credentials. Behind the scene, the IDP provider may use mechanisms like Active Directory or LDAP (Light Weight Directory Access Protocol) to perform the actual authentication

Service Provider (SP): SP refers to one or more systems providing resources to users. The service provider delegates authentication requests to the IDP and verifies user authentication through security tokens like cookies and session identifiers.

SAML Assertion: An XML message conforming to SAML specification used to transfer requests and responses between systems configured to use SAML SSO.

1.    User tries to access an application resource from the service provider (SP)
2.1 If the user is already authenticated (verified through a session cookie), the resource provider returns the requested resource to the user.
2.2 If not already authenticated the service provider redirects the user to the identity provider login page.
3.    User is redirected to the identity provider login page
4.    User enters authentication credentials in the identity provider login page and submits it
5.1 Identity provider authenticates the users. If authentication is not successful, the IDP returns and error page or error message.
5.2 If authentication is successful IDP creates an HTTP request embedded with a SAML assertion (depicting successful authentication) against a pre-configured SP URL.
6.    The browser submits the redirect request from IDP containing SAML assertion to the SP.
7.    If SAML assertion is valid, SP creates a session and returns the requested resource along with a session cookie.

Support for SAML based SSO in typical web applications

The following are the common SAML use cases:
1) Federated SSO using an external IDP using SP initiated login.
2)  IDP initiated logout.
3) SP initiated logout.

The SAML assertions from IDP can be sent through HTTP(S) GET or HTTP(S) POST parameters. Due to possible URL length limits in some browsers, it’s preferable to use HTTP POST for all SAML assertions. SAML assertions are usually send as Base64 encoded strings.

Update 30-Dec-2015: Sample SAML SSO Java code at https://github.com/jubyrajan/saml-auth

Eric Brewer's CAP Theorem & Eventual Consistency

CAP theorem and the concept of "Eventually Consistent" has gained prominence over the last few years. The extreme scalability requirements for massive social networking and content sites has been one of the main driving factors for this.

Brewer's CAP Theorem: There are three core system requirements for designing and deploying data centric applications in a distributed environment; Consistency (C), Availability (A), and Partition Tolerance (P). At a given time a distributed system can guarantee only two of them, an not all the three.

RDBMS vs Non-RDBMS:
In traditional RDBMS systems, transactional consistency is guaranteed by going for Consistency (C) and Availability (A) at the exclusion of Partition Tolerance (P).
In many non-RDBMS persistence mechanisms (particularly the highly scalable NoSQL variants like CouchDB, Voldemort, MongoDB, etc.), Availability (A) and Partition Tolerance (P) is guaranteed at the cost of Consistency (C).

ACID vs Eventually Consistent:
Traditional RDBMS systems can guarantee ACID (Atomicity, Consistency, Integrity, Durability), and in effect tries to ensure that the data is consistent at any given instant. But for most business systems instantaneous consistency is not a real requirement, and most of them can tolerate some time delay for data consistency.

The concept of being "Eventually Consistent", doesn't try to make the data instantaneously consistent but can guarantee that the data will be consistent eventually after a deterministic period of time.

This acceptable relaxation in consistency allows persistence systems like NoSQL to get the benefit of extreme scalability by going for A & P and relaxing the C in CAP.

Eric Brewer's Original Presentation can be found here.
A fairly detailed explanation of CAP by Julian Browne.

Linux Kernel Boot Process In Brief

A brief description of the internals of Linux kernel boot on a PC.

Prelims:-
BIOS finds the boot device and loads the Master Boot Record (MBR). The first 512 bytes in MBR contains the "primary boot loader". Out of the 512 bytes, 446 bytes contains the "primary boot loader" proper, the next 64 bytes contains a partition table, and last two bytes will contain the magic number OxAA55 which acts as a simple validation check.

Stage 1 Boot Loader (Primary Boot Loader):-
Find active partition from the partition table (the 64 bytes in MBR)
Execute the active partition's boot record to load the secondary boot loader (LILO, GRUB, etc.)

Stage 2 Boot Loader (Secondary Boot Loader):-
Read secondary boot loader configuration file (for GRUB this is /etc/grub.conf)
Load default kernel image and initrd image into memory
Invoke the kernel image

Kernel Loading and Initialization:-
start() ./arch/{arch}/boot/head.S
startup_32() ./arch/{arch}/boot/compressed/head.S
decompress_kernel() ./arch/{arch}/boot/compressed/misc.c
startup_32() ./arch/{arch}/kernel/head.S
start_kernel() init/main.c
kernel_thread() arch/{arch}/kernel/process.c
rest_init() init/main.c This creates the first process (PID zero)

An excellent article that explains the process in more detail could be found here.

Javascript on Java

This post illustrates two versions of a simple Java helper class that enables scripting on Java. Its assumed that the reader is aware of the basics of running JavaScript on Java.

The first version uses "Mozilla's Rhino Engine" directly, the second uses the more standard "Java 6" scripting interface (JSR-223).

Using "Mozilla's Rhino Engine" directly:-
import java.util.HashMap;
import java.util.Map;
import org.mozilla.javascript.Context;
import org.mozilla.javascript.Scriptable;

/**
* High level wrapper to Mozilla Rhino Engine.
*/
public class ScriptSession {
private Map scopeObjects = new HashMap();

public void put(String key, Object value) {
scopeObjects.put(key, value);
}

public Object execute(String script) {
Object result = null;
try {
Context ctx = Context.enter();
Scriptable scope = ctx.initStandardObjects();
for(String key : scopeObjects.keySet()) {
scope.put(key, scope, scopeObjects.get(key));
}
result = ctx.evaluateString(scope, script, "embedded_script", 1, null);
} catch(Exception e) {
e.printStackTrace();
} finally {
Context.exit();
}
return result;
}

public static ScriptSession createInstance() {
return new ScriptSession();
}
}


Using Java 6 standard interface:-
import javax.script.ScriptEngine;
import javax.script.ScriptEngineManager;

/**
* High level wrapper to JDK 6 scripting API.
*/
public class ScriptSession {
private ScriptEngine engine;

private ScriptSession() {
ScriptEngineManager factory = new ScriptEngineManager();
engine = factory.getEngineByName("JavaScript");
}

public void put(String key, Object value) {
engine.put(key, value);
}

public Object execute(String script) {
Object result = null;
try {
result = engine.eval(script);
} catch(Exception e) {
e.printStackTrace();
}
return result;
}

public static ScriptSession createInstance() {
return new ScriptSession();
}
}

Usage:-
ScriptSession ss = ScriptSession.createInstance();
// put all the context objects you want using
// session.put("", );
Object result = ss.execute("javascript as text");

Inside JavaScript you can access all your context objects the same way you would access Java objects.