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.

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