A Federated Single Sign-On architecture with multi factor authentication

A high level yet somewhat technical presentation

First some concepts to put everything into context.

A Security Domain is an application or suite of applications that share a common repository of user identities providing authentication credentials and authorization tokens for access control.

Security Domains

Applications in the same security domain consume the same authentication credentials and authorization tokens.

User Identities

Domain A Credentials

Domain A Credentials

Applications in different security domains do not consume authentication credentials and authorization tokens from other domains.

Security Domains

User Identities

User Identities

Single Sign-On (SSO) is an architectural approach used to access multiple security domains. SSO gathers the various authentication credentials of a user from each security domain into a central repository. The repository is accessed by a single set of authentication credentials for a user. When a user requests access to a known security domain the credentials for that domain are passed in to gain access. Single Sign-On vendors have their own proprietary approach.

Single Sign-On

Single Sign-On Portal

User Identities

User Identities

Domain B Credentials

Single Sign-On traverses security domain boundaries but requires a user ‘s identity to be defined in each domain.

Domain A Credentials

SecurityDomain

Credentials

Authentication

Authorization

Authentication

Authorization

Federated Single Sign-On is an industry standards based architectural solution that allows authentication credentials and authorization tokens from disparate security domains to be used to securely access applications across domain boundaries.

Federated Single Sign-On

Federation traverses security domain boundaries without requiring a user’s identity to be defined in each domain

User Identities

Authorization

Authentication

Authorization

Authentication

Multi Factor Authentication

.

Modes of Authentication

Why

How

Using Microsoft’s Forefront Multi-Layered Protection

Protecting Security Domains

Threat Management Gateway (TMG) + Unified Access Gateway (UAG)

Internet

Perimeter NetworkDMZ

Intranet

TMG/UAG

TMG/UAG

Initial line of defense Firewalls to protect the Perimeter Network

User session is established on the perimeter and the request is proxied

TMG/UAG resides on both the Perimeter Network and the Intranet

user requests

Claims Based AuthenticationClaims or Assertions are essentially attributes of an identity that can be used to make informed decisions.

Claim Token (SAML Token)A set of claims (assertions) built by a user’s home Identity Provider (IDP) and passed to the end point application or service, also known as the Relying Party (RP) or Service Provider (SP).

SAML (Security Access Markup Language)An XML-based industry standard protocol used to securely exchange Assertions between trusted business partners (IDP<->SP) .

Providing Federated SSO CapabilitiesFederating with Claims Based Authentication (CBA)

and Secure Access Markup Language (SAML)

CBA is Microsoft’s standard for providing federation capabilities.

SAML is the industry standard used by most everyone else to provide federation capabilities.

A Secure Token Service (STS) provides the ability to utilize either standard.

Providing Federated SSO CapabilitiesFederating with Claims Based Authentication (CBA)

and Secure Access Markup Language (SAML)

Two Factor Implementations PKI Hardware Token. Most expensive and most cumbersome to use

and maintain. For all practical purposes we do not use PKI hardware tokens.

One-Time Password (OTP) Hardware Token such as the SafeWord Token. Initial purchase costs ($50) plus annual maintenance ($20) for each token. We currently use these tokens.

OTP Software Token. Same cost structure as the OTP hardware token.

Two Factor Implementations

OTP delivered to the user’s cell phone, email account or both that does not require specialized tokens or software to be installed by the user.

Costs for hard tokens or soft tokens is eliminated.

Most users already have cell phones and all would have an email address.

Costs can be further reduced by using open source products such as OpenAM to provide the functionality.

AuthenticationRequest

ADFSOpenAM

Active Directory

Radius

SMTP

ADFS provides the Secure Token

Service (STS) translating the

authentication results into the

appropriate claims for the defined

relying parties.

OpenAM performs the actual authentication

process and returns a SAMLv2

AuthNResponse to ADFS. Currently

configured to handle three variations of

authentication – username/password (UP), UP

+ OTP and UP + Secure Token

Active Directory contains the basic single

factor user credential information such as

username and password. It also contains

the information used to send the OTP code

via email/text message.

The RADIUS server

provides verification of the

Secure Token passcode.

The SMTP server

provides the

functionality of sending

the email/text One Time

Passcode (OTP).Relying Party

Federated SSO and Two Factor Authentication

Using Microsoft’s ADFS and ForgeRock’s OpenAM

Two Factor Options

Identity Provider

Authenticate User

AuthenticateOTP Passcode

Return Claims

AuthenticationRequest

Requests User Credentials

Authentication Results

ADFSOpenAM

Active Directory

Radius

Authenticate Secure Token

Passcode

SMTP

Internet

Incoming

Requests

Perimeter

/DMZ

Authentication Logical Flow

SharePointPortal

Send Claims

TMG/UAG

User attempts to access the SharePoint Portal

UAG determines the authentication status and proxies the user’s requestUAG sends

authentication request to ADFS

ADFS delegates OpenAM to act as the user’s IDP

OpenAM requests the user’s credentials

OpenAM validates the credentials against the AD

Two factor options: Hard Token OTP

OpenAM validates the Secure Token passcode against the RADIUS server

Or OpenAM sends the user an OTP passcode to their cell phone and email address

Then OpenAM validates the OTP passcode entered by the user

OpenAM sends a SAML Assertion to ADFS

ADFS transforms the SAML assertion into claims that are sent back to the relying party

The UAG examines the claims and if valid authenticates the user, establishes a session and sends the claims to the SharePoint Portal

Extending the Security Infrastructure

Sounds cost prohibitive but:

Build a new Security Infrastructure

OpenAM

TMG/UAG

ADFS

SQLServerADFS Configuration

Windows Servers

Linux/Unix or

Windows Servers

Extend to a CBA/SAML aware Application or Product

Applications/Products that are already CBA/SAML aware, such as SharePoint 2010, can be configured as a UAG published application in an ADFS trunk to provide CBA authentication and authorizations.

A non CBA/SAML aware application that is not easily enhanced could be configured as a UAG published application to provide CBA authentication and simple authorizations.

An application could be enhanced to be CBA/SAML aware and then configured as a UAG published application. This provides greater flexibility for implementation of more complex authorization schemes. Enhancing an application requires knowledge of CBA/SAML protocols by the programming team who could use existing APIs and tools, both proprietary (Windows) and open sourced (OpenAM), to enhance an application.

Extend to a non CBA/SAML Aware Application or Product

Questions?

Comments?