The Art of Acting Busy at Office

Hilarious but very true:


http://www.great-indian-curry.com/2012/09/the-art-of-acting-busy-at-office.html

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

Hexspeak: Making hexadecimal numbers speak

http://en.wikipedia.org/wiki/Hexspeak