Presentation on theme: "A Federated Single Sign-On architecture with multi factor authentication A high level yet somewhat technical presentation."— Presentation transcript:
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 DomainsSingle Sign-OnFederated Single Sign-OnMulti-Factor Authentication
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
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 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 Security Domain 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 users identity to be defined in each domain User Identities Authorization Authentication Authorization Authentication
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.
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
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 How
Using Microsofts Forefront Multi-Layered Protection Protecting Security Domains Threat Management Gateway (TMG) + Unified Access Gateway (UAG) TMG/UAG Initial line of defense Firewalls to protect the Perimeter Network 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 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 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 users 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 Microsofts 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 Capabilities Federating 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 Users $50 initial purchase $1,000,000 One million Users $20 annual maintenance $400,000
Two Factor Implementations OTP delivered to the users 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.
Federated SSO and Two Factor Authentication Using Microsofts ADFS and ForgeRocks OpenAM Two Factor Options Identity Provider
User attempts to access the SharePoint Portal UAG determines the authentication status and proxies the users request UAG sends authentication request to ADFS ADFS delegates OpenAM to act as the users IDP OpenAM requests the users 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 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 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
Sounds cost prohibitive but: Build a new Security Infrastructure 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.
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