CIS14: Creating a Federated Identity Service for Better SSO

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

•  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

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

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

•  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

Challenges of a Scattered Identity Infrastructure

•  Each application manages its own user list, attributes and is

accessed using different protocols.

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

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

? ? ?

Impl

emen

tatio

n

SAML 2.0 (Open-Id Connect) Federated Access 1.

2. 3. Mapping from internal ID to Tokens?

FEDERATION REQUIRES FEDERATED ACCESS AND

FEDERATED IDENTITY

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.

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


Name=Johnny_Appleseed ID: [email protected]

login=JAppleseed ID=562_09_8000

Salesforce knows Johnny as: [email protected]

Google knows Johnny as: JAppleseed

Value of the Identity Hub and Global Profile

LDAP Directory Active 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

Cor

rela

ted

Iden

tity

View

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


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.

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

•  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

•  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

THE RADIANTONE FEDERATED IDENTITY SERVICE

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

•  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)

•  Map authenticated identity to Enterprise Identity

Identity Mapping Rules

Example Identification Rule: RTC (nameidentifier)à VDS (uid)

= JAppleseed nameidentifier

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

Application Configuration with Templates

•  Retrieve attributes applicable to the application and map/transform them accordingly.

•  Built-in functions simplify the mapping/transformation.

Application Token Mapping Rules

User experience: CFS Portal

SSO to Applications

User Self-Service: Edit profile attributes, reset-password

White Pages: Search for users

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

Reference Image for Provisioning

Legacy Applications (and respective stores)

AD Sun LDAP

Cloud Apps

LDAP/ SQL/ SPML

SPML SCIM

•  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

•  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

•  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

•  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

•  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

CIS14: Creating a Federated Identity Service for Better SSO

Technology

Transcript of CIS14: Creating a Federated Identity Service for Better SSO