1 / 23

Secure Single Sign-On Across Security Domains

Secure Single Sign-On Across Security Domains. 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.

etan
Download Presentation

Secure Single Sign-On Across Security Domains

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Secure Single Sign-OnAcross 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.

  3. Security Domains • A Security Domain is an application or suite of applications that share a common repository of user identities providing authenticationcredentials and authorization tokens for access control. Security Domain A Case Management User Identities Investigative Domain A Credentials Auditing 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 Security Domain B Case Management User Identities SharePoint Portal Investigative Domain A Credentials Auditing 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. Security Domain A Security Domain B Case Management SharePoint Portal Single Sign-On Portal Security Domain Credentials Investigative 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 Auditing 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. Authentication Authentication Authentication Authentication Security Domain B Security Domain A Federation traverses security domain boundaries without requiring a user’s identity to be defined in each domain Case Management SharePoint Portal Security Domain C User Identities Investigative Authorization Authorization Authorization Authorization Auditing

  7. Multi Factor Authentication .

  8. Modes of Authentication Somewhat Secure Very Secure

  9. Why

  10. How

  11. Protecting Security Domains • Using Microsoft’s Forefront Multi-Layered Protection Threat Management Gateway (TMG) + Unified Access Gateway (UAG) TMG/UAG Highlights 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.

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

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

  17. User attempts to access the SharePoint Portal UAG determines the authentication status and proxies the user’s request Two factor options: Hard Token OTP UAG sends authentication request to ADFS The UAG examines the claims and if valid authenticates the user, establishes a session and sends the claims to the SharePoint Portal Putting it all together Putting it all together 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 validates the Secure Token passcode against the RADIUS server 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

  19. Build a new Security Infrastructure • Sounds cost prohibitive but:

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

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

  22. Questions? Comments?

More Related