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.
Security Domains
Single Sign-On
Federated Single Sign-On
Multi-Factor Authentication
Security Domains
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.
Case
Management
User
Identities
Investigative
Domain A
Credentials
Auditing
Applications in the same security domain consume the same authentication
credentials and authorization tokens.
Security Domains
Applications in different security domains do not consume authentication
credentials and authorization tokens from other domains.
Case
Management
User
Identities
Domain A
Credentials
Investigative
Auditing
User
Identities
SharePoint
Portal
Single Sign-On
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
Portal
Security
Domain
Credentials
Domain
AB
Domain
Credentials
Credentials
Single Sign-On traverses security domain boundaries but
requires a user ‘s identity to be defined in each domain.
User
Identities
Case
Management
Investigative
Auditing
User
Identities
SharePoint
Portal
Federated Single Sign-On
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.
Federation traverses security domain boundaries
without requiring a user’s identity to be defined in
each domain
Case
Management
Authentication
Investigative
Authorization
Auditing
Authentication
Authentication
SharePoint
Portal
Authorization
Authorization
User
Identities
Multi Factor Authentication
Something you know
• Username, password, pin, etc.
Something you have
• Cell phone, digital token, email address, etc.
Something you are
• Fingerprint, voice, retina, etc.
.
Modes of Authentication
Single Factor –
Something I know
Two Factor –
Something I know
and Something I
have
Why
Why Single Sign-On?
• Increases productivity while reducing frustration
• Removes the need for a user to constantly remember the password for each
security domain
Why Federated Single Sign-On?
• Eliminates the need for a user identity to exist in each security domain
• Eliminates multiple user identities for the same user
• Eliminates the need for the user to have multiple passwords
• Reduces user identity management costs
• Adheres to Industry Standards
Why Multi-Factor Authentication?
• Simple user name/password can be easily compromised
• Passwords are often written on sticky notes or left laying around
• Passwords are usually too simple, common or short
• Multi-Factor Authentication is not easily compromised
How
To protect a security domain or
multiple security domains
To provide Federated SSO capabilities
to the security infrastructure
To implement cost efficient two-factor
authentication
To extend the security infrastructure
umbrella
Protecting Security Domains
Using Microsoft’s Forefront Multi-Layered Protection
Threat Management Gateway (TMG) + Unified Access Gateway (UAG)
Internet
Application Layer Firewall
user requests
Initial line of defense
Firewalls to protect the Perimeter Network
White List Access
User session is established on the
perimeter and the request is
proxied
Perimeter Network
DMZ
HTTP/Packet/URL filtering
SSL Tunneling/VPN
Forward/Reverse/Web proxy
TMG/UAG resides on both the
Perimeter Network and the Intranet
Intrusion Detection and Prevention
Intranet
Information Leakage Prevention
URL Rewrites
Providing Federated SSO Capabilities
Federating with Claims Based Authentication (CBA)
and Secure Access Markup Language (SAML)
Claims Based Authentication
Claims 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 Capabilities
Federating 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.
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.
20000
Users
$50 initial
purchase
20000 Users
$20 annual
maintenance
$1,000,000
One
million
$400,000
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.
Federated SSO
and
Two
Factor
Authentication
Using Microsoft’s ADFS and ForgeRock’s OpenAM
The SMTP server
provides the
functionality of sending
the email/text One Time
Passcode (OTP).
R
SMTP
a r ty
P
g
n
elyi
Two Factor Options
Authentication
Request
Radius
The RADIUS server
provides verification of the
Secure Token passcode.
Identity Provider
ADFS
OpenAM
Active Directory
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.
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
ADFS provides the Secure Token
Service (STS) translating the
authentication results into the
appropriate claims for the defined
relying parties.
User attempts to access
the SharePoint Portal
e
Int
Incoming
Requests
t
rn e
Perimeter
/DMZ
SMTP
UAG determines the authentication
status and proxies the user’s request
Two factor options:
Hard Token
OTP
Authenticate
OTP Passcode
UAG
sends
authentication
The
UAG
examines
the
request
to
ADFS
claims and if valid
authenticates the user,
Send
establishes a session
Claims
and sends the claims to
the SharePoint Portal
Radius
OpenAM
Authenticate
validates the
Secure Token
Secure Token
Passcode
passcode against
the RADIUS
server
Or
OpenAM
sends the
Then
OpenAM
user
an OTP
validates
thepasscode
OTP
topasscode
their cellentered
phone and
by
email
address
the user
Authenticate
User
OpenAM validates
the credentials
against the AD
Active Directory
SharePoint
OpenAM
Portal
requests the
user’s credentials
Requests
User Credentials
TMG/UAG
Authentication
Request
ADFS transforms the SAML assertion
into claims that are sent back to the
relying party
ADFS delegates OpenAM
to act as the user’s IDP
OpenAM sends a SAML Assertion to ADFS
OpenAM
Return
Claims
Authentication
Results
Authentication Logical Flow
ADFS
Extending the Security Infrastructure
Extend by building a new Security
Infrastructure
Extend to a CBA/SAML aware
application or product
Extend to a non CBA/SAML aware
application or product
Build a new Security Infrastructure
Sounds cost prohibitive but:
You may have an Enterprise Client Access License (CAL) from Microsoft
granting the use of ForeFront UAG. And if you use Microsoft Server
2008R2 you can add a role for ADFSv2
Existing identity stores (Active Directory or LDAP) are already in place.
Email/SMS gateway is probably already in place
OpenAM is open source and freely available
The network infrastructure is probably already in place
You would need to provide Windows Servers or VMs for the UAG, ADFS
and ADFS configuration database.
You would need to provide the servers for OpenAM. Requires a web
application server supporting Java 1.5 or higher which could be an
open source product such as Tomcat.
TMG/UAG
o
nd
Wi
ws
S
e
erv
ADFS
ADFS
OpenAM
Linux/Unix or
Windows Servers
SQLServer
ADFS Configuration
rs
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.
Extend to a non CBA/SAML Aware Application or Product
 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.
Questions?
Comments?