CIS14: Creating a Federated Identity Service for Better SSO
1 like999 views
The document discusses the challenges of fragmented identity systems in large enterprises and introduces the RadiantOne Federated Identity Service as a solution to simplify deployment, management, and security through federation. It highlights the need for a unified identity provider (IdP) to navigate multiple authentication systems and streamline access to various applications. The service supports multi-tenancy, enhances security with multi-factor authentication, and allows for adaptability to organizational needs and changes.
CIS14: Creating a Federated Identity Service for Better SSO
- 1. What's Under Your Cloud? On-Premises IdP for Today's Business Creating a Federated Identity Service for Better SSO Matt Tatro – Midwest Sales Manager – Radiant Logic Denise Lores – Solution Architect – Radiant Logic
- 2. • Describe the challenges around moving to cloud apps for large enterprises consisting of many heterogeneous user stores. • Introduce Federation concepts and requirements. • Introduce the RadiantOne Federated Identity Service as a key piece of infrastructure to radically simplify deployment, management, and security by federating identity to provide one logical access point to the cloud. Agenda
- 3. The World of Access Keeps Expanding App sourcing and hosting User populations App access channels SasS apps Apps in public clouds Partner apps Apps in private clouds On-premise enterprise apps Enterprise computers Enterprise-issued devices Public computers Personal devices Employees Contractors Customers Partners Members
- 4. The Challenge of a Fragmented Distributed Identity System AD Forest/Domain A Identity Sources AD Forest/Domain B Databases Internal Enterprise Apps Directories Cloud Apps Look familiar? This is why many clients report that the business views them as a bottleneck
- 5. • A wide range of identity stores are maintained for internal users, partners/suppliers and customers. • On average, large enterprises have: • 41 stores for internal users • 71 stores for partners/suppliers • 62 stores for customers • 75% of internal users and 38% of external users are in multiple directories • Organizations manage user attributes in, on average around 13 different data stores! • By 2020, 70% of enterprises will use ABAC as the dominant mechanism to protect critical assets, up from less than 5% today (Gartner) Reality: Multiple Heterogeneous Data Stores Osterman Research Survey Findings
- 6. Challenges of a Scattered Identity Infrastructure • Each application manages its own user list, attributes and is accessed using different protocols.
- 7. Mapping identities across SaaS applications Obstacle for STS to achieve true SSO LDAP Directory Active Directory employeeNumber=E562098000Z samAccountName=Johnny_Appleseed objectClass=user mail: [email protected] departmentNumber=234 memberOf=Sales memberOf=AllUsers memberOf=InventoryRead uid=JAppleseed Otle=VP Sales givenName=Johnny sn=Appleseed departmentNumber=234 employeeID=562_09_8000 isMemberOf=InternalUsers Name=Johnny_Appleseed ID: [email protected] login=JAppleseed ID=562_09_8000 Salesforce knows Johnny as: [email protected] Google knows Johnny as: JAppleseed
- 8. Federation is the Solution But deployment is often the challenge! Federation Cloud Apps Federation requires An Identity Provider (Idp) Internal Authentication and SSO? Attributes for authorization? Enterprise Identity Data Sources ? ?? Implementation SAML 2.0 (Open-Id Connect) Federated Access1. 2. 3. Mapping from internal ID to Tokens?
- 9. FEDERATION REQUIRES FEDERATED ACCESS AND FEDERATED IDENTITY
- 10. Simplify and/or Evolve your IdP deployment with a Federated Identity Hub The identity hub component federates identity from across the infrastructure into a single hub, rationalizing duplicate accounts as necessary. The STS component sends user information to applications in secure tokens to perform external federation. This layer is provided by vendors such as PING and ADFS.
- 11. Mapping identities across SaaS applications LDAP Directory Active Directory employeeNumber=E562098000Z samAccountName=Johnny_Appleseed objectClass=user mail: [email protected] departmentNumber=234 memberOf=Sales memberOf=AllUsers memberOf=InventoryRead uid=JAppleseed Otle=VP Sales givenName=Johnny sn=Appleseed departmentNumber=234 employeeID=562_09_8000 isMemberOf=InternalUsers Name=Johnny_Appleseed ID: [email protected] login=JAppleseed ID=562_09_8000 Salesforce knows Johnny as: [email protected] Google knows Johnny as: JAppleseed
- 12. Value of the Identity Hub and Global Profile LDAP DirectoryActive Directory employeeNumber=E562098000Z samAcountName=Johnny_Appleseed objectClass=user mail: [email protected] uid=JAppleseed title=VP Sales departmentNumber=234 memberOf=Sales memberOf=AllUsers memberOf=InventoryRead memberOf=InternalUsers ref = cn=johhny_appleseed,dc=ad,dc=vds ref = uid=JAppleseed,dc=ldap,dc=vds CorrelatedIdentityView CorrelaOon rules/logic. An exisOng single unique idenOfier not required. This provides the reference image for claims! employeeNumber=E562098000Z samAccountName=Johnny_Appleseed objectClass=user mail: [email protected] departmentNumber=234 memberOf=Sales memberOf=AllUsers memberOf=InventoryRead uid=JAppleseed Otle=VP Sales givenName=Johnny sn=Appleseed departmentNumber=234 employeeID=562_09_8000 isMemberOf=InternalUsers
- 13. Token Contents are Not Standardized SAML Attribute Set B SAML Attribute Set C SAML Attribute Set A SAML defines a common framework, a “menu” of information in a common format from which applications can choose which they require. The appropriate subset of attributes required by the Service Provider, is encrypted in a token, and sent to the SP, by an Identity Provider.
- 14. APPLICATION LAYER VIRTUALIZATION LAYER DATA SOURCES Directories Databases Web Services Active Directory Together CFS and VDS act as a complete Identity Provider, authenticating users, gathering their attributes, and sending them in the appropriate format in security tokens to applications. CFS is the Security Token Service RadiantOne Virtual Directory Service (VDS) is the federated identity hub RadiantOne Federated Identity Service VDS + CFS offers a complete IdP
- 15. • Because the commonly used federation standards (like SAML and WS- Federation) don’t enforce a rigid set of attributes that all applications must accept, the IdP must generate a different token for each Service Provider. • Would you turn away a business partner because your IdP won’t mesh with their apps? The IdP Must Generate Applicable Token Mappings Token Contents: Authentication Attributes email Certificate_id Authorization Attributes Groups Roles Identity Provider Token Contents: Authentication Attributes UPN ImmutableID nameidentifier Authorization Attributes Groups
- 16. • In many scenarios, an Identity Provider will have to search for a user in more than one Authentication System. An IdP must be able to navigate this “last mile” to authenticate users and gather attributes • Avoid a lengthy, costly re-architecture of the identity repository you intend to act as your IdP The IdP Must Support Multiple Authentication Systems AUTHENTICATION SYSTEMS • Handle authentication of the users. • Return necessary attributes to the Identity Provider, to be used for authorization. Identity Provider
- 17. THE RADIANTONE FEDERATED IDENTITY SERVICE
- 18. Support for Multiple Authentication Systems • CFS supports the following systems for authenticating users: 1. Forms Based Authentication through VDS (essential for mobile devices!). Users enter their credentials, and VDS delegates the authentication to the authoritative enterprise identity store. 2. Radiant Trust Connectors (RTCs) allow users stored in Active Directory to be authenticated in their local domain using Windows Integrated Authentication (Kerberos/NTLM – Windows Integrated Authentication). 3. Certificate Authentication through VDS. 4. Leverage third party trusted IDP: FaceBook, Twitter, PayPal, ADFS 2, Azure ACS, OpenAM
- 19. • The Radiant Trust Connector (RTC) is an application that runs inside IIS. IIS handles authentication with Windows Integrated Authentication – either via Kerberos or NTLM. • RTCs handle the retrieval of user data from Internet Information Services and pass the user data to CFS (via the browser) in a token. CFS then matches the identity from the RTC with an identity in VDS, and transforms the user data into the claim format the application expects, thus enabling SSO for AD users. How CFS federates Active Directory domains (Similar Implementation than with ADFS)
- 20. • Map authenticated identity to Enterprise Identity Identity Mapping Rules Example Identification Rule: RTC (nameidentifier)à VDS (uid) = JAppleseednameidentifier employeeNumber=E562098000Z samAcountName=Johnny_Appleseed objectClass=user mail: [email protected] uid=JAppleseed title=VP Sales departmentNumber=234 memberOf=Sales memberOf=AllUsers memberOf=InventoryRead memberOf=InternalUsers ref = cn=johhny_appleseed,dc=ad,dc=vds ref = uid=JAppleseed,dc=ldap,dc=vds
- 21. Application Configuration with Templates
- 22. • Retrieve attributes applicable to the application and map/transform them accordingly. • Built-in functions simplify the mapping/transformation. Application Token Mapping Rules
- 23. User experience: CFS Portal SSO to Applications User Self-Service: Edit profile attributes, reset-password White Pages: Search for users
- 24. Support for both IdP-initiated and SP-initiated Sessions For IdP-initiated access, the user can login to the CFS Portal and select which application they would like to access. For SP-initiated access, the user can attempt to access the application first, and then be redirected to the CFS portal site for authentication. Or if the user has already been authenticated by CFS, they will gain access to the application without having to re-authenticate. http://sharepointsite
- 25. Reference Image for Provisioning Legacy Applications (and respective stores) AD Sun LDAP Cloud Apps LDAP/ SQL/ SPML SPML SCIM
- 26. • Support for Multi tenancy • For the large enterprise wishing to act as an IdP for third parties, multi tenancy allows the storage of third-party identities on-premises to provide access to cloud applications. • User registration and management • Increased end user security • 2-Step Verification (Multi Factor Authentication) • Requires user name/password and passcode to login. • Passcode can be sent via an Authenticator app on user’s mobile device or emailed. • New Access Control Mechanisms: • Levels of Assurance • Circle of Trust Additional Capabilities to Consider
- 27. • Each authentication system is assigned a level of assurance (examples shown for Active Directory and Forms-based (with and w/o 2 step verification). • Each application is assigned a level of assurance. Level of Assurance Configuration
- 28. • When a user logs in, the level of assurance associated with their chosen authentication system will be one of the criteria used by CFS to enforce access to applications. Enforcing Access Based on Level of Assurance
- 29. • When a user logs in, the CoT rules will be evaluated to determine which are applicable. • For example, if the following rules are defined, and a user logs in from a client with the IP address of 10.11.12.5, then Location=headquarters will be used as criteria for determining which applications the user should have access to. Circle of Trust (CoT) E.g. CoT Rules Defined E.g. CoT Rules Assigned to an Application
- 30. • Simplify the Move Cloud Apps • There is a lot of focus on federating user access, but you also need to federate your identities! Especially for large, complex identity infrastructures that have: • No single AD domain containing all users • Duplicate user accounts across AD domains and forests • Users outside of AD sources (extend authentication to and/or retrieve profile attributes from) • Have a single logical place to authenticate users and retrieve a rationalized view of groups. • Use the global reference image to provision to cloud applications. • Expand an existing Federation deployment easily • Support new user populations • Support new application requirements • Address custom data requirements • Customizations/computations can be done at the RadiantOne layer, not by the IdP, letting them focus on the token creation/translation they provide. • Each application can have their own “virtual view” (specific mappings, computations, attributes). • Maximize your ROI • Re-use the Federated Identity Service layer for other initiatives: • Other applications (e.g. Cisco Unified Communications Manager, Qumu, SiteMinder, SharePoint…etc.) Conclusion