Presentation on theme: "Secure Single Sign-On Across Security Domains"— Presentation transcript:
1 Secure Single Sign-On Across Security Domains A Federated Single Sign-On architecture with multi factor authenticationA high level yet somewhat technical presentation
2 First some concepts to put everything into context. Security DomainsSingle Sign-OnFederated Single Sign-OnMulti-Factor Authentication
3 Security DomainsA 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 ACase ManagementInvestigativeAuditingUserIdentitiesDomain A CredentialsSecurity 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 DomainsApplications in different security domains do not consume authentication credentials and authorization tokens from other domains.Security Domain ACase ManagementInvestigativeAuditingUserIdentitiesDomain A CredentialsSecurity domains are normally contained within the same network infrastructure yet multiple security domains can, and often do, exist within the same network.Security Domain BSharePointPortalUserIdentities
5 Single Sign-OnSingle 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-OnPortalSecurityDomainCredentialsDomain A CredentialsDomain B CredentialsSingle Sign-On traverses security domain boundaries but requires a user ‘s identity to be defined in each domain.Security Domain ACase ManagementInvestigativeAuditingSecurity Domain BSharePoint PortalUserIdentitiesUserIdentities
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 domainSecurity Domain AInvestigativeCase ManagementAuditingSecurity Domain CAuthenticationAuthorizationUserIdentitiesAuthenticationAuthorizationAuthorizationAuthenticationSecurity Domain BSharePoint Portal
7 Multi Factor Authentication Username, password, pin, etc.Something you knowCell phone, digital token, address, etc.Something you haveFingerprint, voice, retina, etc.Something you are.
8 Modes of Authentication Single Factor – Something I knowTwo Factor – Something I know and Something I haveSomewhat SecureVery Secure
9 Why Why Single Sign-On? Why Federated Single Sign-On? Increases productivity while reducing frustrationRemoves the need for a user to constantly remember the password for each security domainWhy Federated Single Sign-On?Eliminates the need for a user identity to exist in each security domainEliminates multiple user identities for the same userEliminates the need for the user to have multiple passwordsReduces user identity management costsAdheres to Industry StandardsWhy Multi-Factor Authentication?Simple user name/password can be easily compromisedPasswords are often written on sticky notes or left laying aroundPasswords are usually too simple, common or shortMulti-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 infrastructureTo implement cost efficient two-factor authenticationTo extend the security infrastructure umbrella
11 Protecting Security Domains Using Microsoft’s Forefront Multi-Layered ProtectionThreat Management Gateway (TMG) + Unified Access Gateway (UAG)TMG/UAG HighlightsApplication Layer FirewallWhite List AccessHTTP/Packet/URL filteringSSL Tunneling/VPNForward/Reverse/Web proxyIntrusion Detection and PreventionInformation Leakage PreventionURL Rewritesuser requestsInitial line of defenseFirewalls to protect the Perimeter NetworkUser session is established on the perimeter and the request is proxiedTMG/UAGSecurity Domain BTMG/UAGTMG/UAG resides on both the Perimeter Network and the IntranetSecurity Domain A
12 Providing Federated SSO Capabilities Federating with Claims Based Authentication (CBA)and Secure Access Markup Language (SAML)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) .
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,000One million20000 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 OpenAMTwo Factor OptionsIdentity Provider
17 Putting it all together Putting it all together User attempts to access the SharePoint PortalUAG determines the authentication status and proxies the user’s requestTwo factor options:Hard TokenOTPThe UAG examines the claims and if valid authenticates the user, establishes a session and sends the claims to the SharePoint PortalUAG sends authentication request to ADFSPutting it all togetherPutting it all togetherOr OpenAM sends the user an OTP passcode to their cell phone and addressOpenAM validates the Secure Token passcode against the RADIUS serverThen OpenAM validates the OTP passcode entered by the userADFS transforms the SAML assertion into claims that are sent back to the relying partyOpenAM requests the user’s credentialsADFS delegates OpenAM to act as the user’s IDPOpenAM validates the credentials against the ADOpenAM sends a SAML Assertion to ADFS
18 Extending the Security Infrastructure Extend by building a new Security InfrastructureExtend to a CBA/SAML aware application or productExtend 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 ADFSv2Existing identity stores (Active Directory or LDAP) are already in place./SMS gateway is probably already in placeOpenAM is open source and freely availableThe network infrastructure is probably already in placeYou 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.