1. Secure Single Sign-On Across Security Domains
A Federated Single Sign-On architecture with multi factor authentication
A high level yet somewhat technical presentation

2. First some concepts to put everything into context.
Security Domains
Single Sign-On
Federated Single Sign-On
Multi-Factor Authentication

3. 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.
Security Domain A
Case Management
Investigative
Auditing
User
Identities
Domain A Credentials
Security domains are normally contained within the same network infrastructure yet multiple security domains can, and often do, exist within the same network.
Applications in the same security domain consume the same authentication credentials and authorization tokens.

4. Security Domains
Applications in different security domains do not consume authentication credentials and authorization tokens from other domains.
Security Domain A
Case Management
Investigative
Auditing
User
Identities
Domain A Credentials
Security domains are normally contained within the same network infrastructure yet multiple security domains can, and often do, exist within the same network.
Security Domain B
SharePoint
Portal
User
Identities

5. 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 A Credentials
Domain B Credentials
Single Sign-On traverses security domain boundaries but requires a user ‘s identity to be defined in each domain.
Security Domain A
Case Management
Investigative
Auditing
Security Domain B
SharePoint Portal
User
Identities
User
Identities

6. 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
Security Domain A
Investigative
Case Management
Auditing
Security Domain C
Authentication
Authorization
User
Identities
Authentication
Authorization
Authorization
Authentication
Security Domain B
SharePoint Portal

7. Multi Factor Authentication
Username, password, pin, etc.
Something you know
Cell phone, digital token, address, etc.
Something you have
Fingerprint, voice, retina, etc.
Something you are .

8. Modes of Authentication
Single Factor – Something I know
Two Factor – Something I know and Something I have
Somewhat Secure
Very Secure

9. Why Why Single Sign-On? Why Federated 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

10. 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

11. Protecting Security Domains
Using Microsoft’s Forefront Multi-Layered Protection
Threat Management Gateway (TMG) + Unified Access Gateway (UAG)
TMG/UAG Highlights
Application Layer Firewall
White List Access
HTTP/Packet/URL filtering
SSL Tunneling/VPN
Forward/Reverse/Web proxy
Intrusion Detection and Prevention
Information Leakage Prevention
URL Rewrites
user requests
Initial line of defense
Firewalls to protect the Perimeter Network
User session is established on the perimeter and the request is proxied
TMG/UAG
Security Domain B
TMG/UAG
TMG/UAG resides on both the Perimeter Network and the Intranet
Security Domain A

12. 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) .

13. 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.

14. 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
$1,000,000
One million
20000 Users
$20 annual maintenance
$400,000

15. Two Factor Implementations
OTP delivered to the user’s cell phone, 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 address.
Costs can be further reduced by using open source products such as OpenAM to provide the functionality.

16. Federated SSO and Two Factor Authentication
Using Microsoft’s ADFS and ForgeRock’s OpenAM
Two Factor Options
Identity Provider

17. Putting it all together Putting it all together
User attempts to access the SharePoint Portal
UAG determines the authentication status and proxies the user’s request
Two factor options:
Hard Token
OTP
The UAG examines the claims and if valid authenticates the user, establishes a session and sends the claims to the SharePoint Portal
UAG sends authentication request to ADFS
Putting it all together
Putting it all together
Or OpenAM sends the user an OTP passcode to their cell phone and address
OpenAM validates the Secure Token passcode against the RADIUS server
Then OpenAM validates the OTP passcode entered by the user
ADFS transforms the SAML assertion into claims that are sent back to the relying party
OpenAM requests the user’s credentials
ADFS delegates OpenAM to act as the user’s IDP
OpenAM validates the credentials against the AD
OpenAM sends a SAML Assertion to ADFS

18. 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

19. 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.
/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.

21. 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.

22. 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.

23. Questions?
Comments?