CIS14: Creating a Federated Identity Service for Better SSO

728 views

Published on

Matt Tatro, Denise Lores, Wade Ellery
Radiant Logic
How to avoid building half an Enterprise IdP; demonstration of how to create a federated identity service that will complement and improve your SSO by aggregating all of your identity silos into an enterprise IdP.

Published in: Technology
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
728
On SlideShare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
26
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide

CIS14: Creating a Federated Identity Service for Better SSO

  1. 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. 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. 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. 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. 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. 6. Challenges of a Scattered Identity Infrastructure •  Each application manages its own user list, attributes and is accessed using different protocols.
  7. 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:  johnny_appleseed@setree1.com   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:  johnny_appleseed@setree1.com   login=JAppleseed   ID=562_09_8000   Salesforce  knows  Johnny  as:   johnny_appleseed@setree1.com   Google  knows  Johnny  as:   JAppleseed  
  8. 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. 9. FEDERATION REQUIRES FEDERATED ACCESS AND FEDERATED IDENTITY
  10. 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. 11. Mapping identities across SaaS applications LDAP Directory Active Directory employeeNumber=E562098000Z   samAccountName=Johnny_Appleseed   objectClass=user   mail:  johnny_appleseed@setree1.com   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:  johnny_appleseed@setree1.com   login=JAppleseed   ID=562_09_8000   Salesforce  knows  Johnny  as:   johnny_appleseed@setree1.com   Google  knows  Johnny  as:   JAppleseed  
  12. 12. Value of the Identity Hub and Global Profile LDAP DirectoryActive Directory employeeNumber=E562098000Z samAcountName=Johnny_Appleseed objectClass=user mail: johnny_appleseed@setree1.com 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:  johnny_appleseed@setree1.com   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. 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. 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. 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. 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. 17. THE RADIANTONE FEDERATED IDENTITY SERVICE
  18. 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. 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. 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: johnny_appleseed@setree1.com 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. 21. Application Configuration with Templates
  22. 22. •  Retrieve attributes applicable to the application and map/transform them accordingly. •  Built-in functions simplify the mapping/transformation. Application Token Mapping Rules
  23. 23. User experience: CFS Portal SSO to Applications User Self-Service: Edit profile attributes, reset-password White Pages: Search for users
  24. 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. 25. Reference Image for Provisioning Legacy Applications (and respective stores) AD Sun LDAP Cloud Apps LDAP/ SQL/ SPML SPML SCIM
  26. 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. 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. 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. 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. 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

×