Secure Sign-on for Web-based Applications (SAML)

SAML stands for "Security Assertion Markup Language". It is an XML-based standard for communicating identity information between users and web applications service providers. The primary function of SAML is to provide an Internet Single Sign-On (SSO) for organizations looking to securely connect with Internet webs that exist both in the inside as well as on the outside of an organization's firewall.

Internet SSO is a secure connection where identity and trust is shared between a specified security certification Partner and a web an application provider. Such SSOs streamlines the access to applications by eliminating logins for individual applications. Logins are avoided by providing a persistent SSO. For instance, once a SAML SSO has been approved for a user to a Google SaaS service no further logins are required.

The Security Assertion Markup Language (SAML) is an OASIS (Organization for the Advancement of Structured Information) standard for exchanging authentication data. It uses security tokens to pass information about an end-user and an identity provider. IBM, Oracle, RSA, VMware, HP and Google support SAML.

How SAML authorizations are executed depends on how applications are hosted. Services vendors, and particularly various Infrastructure-as-a-Service (IaaS) or Platform-as-a-Service (PaaS), will offer different middleware versions for accepting SAML. This will limit the extent how applications can be relocated to other vendors.

The simplest use of SAML can be found for Google, which is the premier Software-as-a-Service (SaaS) offering:

The following describes the steps taken to obtain a SAML access authorization:

1.      The user attempts to reach a hosted Google application.

2.     Google generates a SAML authentication request.

3.     Google sends a redirect to the user's browser. The redirect URL includes the SAML authentication that will be submitted to the Partner.  

4.     The Partner decodes the SAML request and extracts the URL for both Google and the user's destination URL. The Partner will then authenticate the user.

5.     The Partner generates a SAML response that contains the authenticated user's username. This response is digitally signed with the partner's public or private RSA key.

6.     The Partner encodes the SAML response and returns that information to the user so that the user’s browser can forward that information to Google.

7.     Google verifies the SAML response using the Partner's public key. If that is confirmed it redirects the user to the Google application.

8.     The user is now logged to all Google SaaS applications.

SUMMARY

The step-by-step process described above represents only the simplest case of a SAML authorization process. In the case of Google this makes the use of Google applications not only rapid but also convenient as a preferred service.

From the standpoint of DoD the required SAML SSO authorizations can be specified for every user. Different security clearances can be attributed according to need-to-know uses.

The accreditation Partner should be organized within DoD. It should be also staffed by DoD manpower at Network Control Centers that track application access by each DoD person.

The current access authorization process in DoD is based on Common Access Card (CAC) readers.  The user then logs to applications to obtain access privileges. There may hundreds of such separate logon procedures presently in place. Such logons were conceived when applications were developed in separate contracts. Single Sign On (SSO) is used only in application “silos”. The multiplicity of SSO processes increases the costs as well as a vulnerability to security compromises.

The DoD should therefore consider adopting a customized version of SAML initially for all of its web applications and subsequently for all of its SaaS applications.