1. Identity and Context Virtualization The Key to Your IdM Architecture

2. “Everything You Know About IdM Is Wrong” Neil McDonald, Gartner IAM Summit

3. Gartner: Contextual Virtual Identity
"By year-end 2009, 80 percent of organizations deploying IAM solutions will use
virtual directory technology as part of the IAM infrastructure"

4. It’s About Virtualizing Both Identity and Context

5. “Virtual Directories: Valuable Present, Promising Future” Mark Diodati, Burton Group
Market Leader
“The Radiant Logic VDS product has been in the market for 8 years and is the leader in the virtual directory market”

6. Customer Implementation
Vision / Nirvana •
A Single Secure Identity Service –
Seamless Authentication & Authorization –
Single point to provision access –
Internal & External Users •
Levels of Authentication based upon risk •
Easier access to user object data

7. Customer Implementation
Identity Architecture
Identity Management Service
IdM Access Services
Authentication
User Object Data
Access
Authorization
Provisioning
Engine
Virtual Directory
Enterprise Directory
MetaDirectory
Manager
Authoritative Sources
Network
Operating System
Active Directory
FRB
Groupware /
Board
Mainframe
HR Human
Capital
Management
System
Identity
Virtualization Layer

8. Our Customers are our Best Testimonials

9. Identity and Context Virtualization One Infrastructure: Many Services
VDS
Different Virtual Directory views for different services
A common identity The Virtual Identity Hub
ICS

10. Top 4 Common Use Cases for Identity and Context Virtualization
Authentication (WAM, Portal, SM, TAM, RSA, Ping)
Integrating identities: Internal vs. External, Employees/Customers…etc…
The challenges and opportunities brought by Active Directory
Multiple domains/forests
Authorization (Roles, Rules, SM, RSA,TAM, Policy Server)
Context are generally defined in applications that use databases
Delegated Administration
segregation of duties
specialized contextual views
Global/Enterprise Information Server for structured data (moving from a directory as a context server)

11. Use Case: Authentication (Identity Union)
Challenges:
First step in authentication is identification (finding the user entry that needs to authenticate)
Identities are spread across multiple data sources (e.g. multiple AD domains/forests…etc)
Identities are described differently in each source (e.g. FirstName vs. fname vs. givenName)
Second step is credentials checking. Each source supports its own authentication mechanism
Different encryption of passwords and schema elements (userPassword vs. unicodePwd…etc).
Existing internal user IDs, passwords in Active Directory
External users credentials may be stored elsewhere (SunOne, Oracle…etc)
Virtualization solves the authentication problem
Aggregating users from multiple data sources (allow applications to search one common namespace to find the user)
Credentials checking can be handled at the virtual directory layer, or by the underlying source (delegated authentication)

12. Three Main Challenges Associated with the Identification (Search) Phase of the Authentication
Locating the user where to search for them
If there is more than one place, the challenge becomes where to search and in which order
Having a common representation of the user info
Schema conversion, objectclass and attributes mapping (e.g. InetorgPerson in Sun vs. User in AD, vs person table in database)
Distinguishing between the different identifiers for the same person….
LCallahan, LauraC…
is essentially an integration challenge the lack of an integrated view of identity

13. Authentication Step 1: Identification
Locate the user entry (based on who logs in)
Databases
Applications
Directories
User information spread across multiple heterogeneous sources and stored differently

14. Example: Identification Challenges with Multiple Active Directory Forests/Domains
VDS
o=vds
ou=AD List
ou=AD1
ou=AD2
ou=AD3
Active Dir Domain 1
Active Dir Domain 2
Active Dir Domain 3
One entry point to access all Active Directory domains/forests (mount all AD domains into the virtual namespace)
dc=us
dc=us.corp
dc=cis
ou=internal
ou=groups
ou=dept
ou=sales
ou=temps
ou=Admin
ou=Con
ou=sales
ou=mktg
cn=novato_branch

15. Identification: Create an Aggregated List of User Entries
Aggregation/linking establish a complete list of User Entries
All schemas are mapped to a common schema
All users can be found/identified in the virtual namespace

16. Aggregation vs. Integration: Union, Intersection (correlation where needed)
* Here mention that will revisit this case a bit later when we look at the existence of a common key /identifier across the virtualized sources
Reduced sign on is possible only if an identity exists (and
has been be detected/correlated) across different security domains

17. Authentication Step 2: Credentials Checking
Authentication Mechanism
Password encryptions
Databases
Applications
Directories
Passwords encrypted using custom algorithm
Passwords encrypted using custom algorithm
Passwords encrypted using SSHA

18. Authentication Step 2: Credential Checking
Multiple authentication mechanisms supported
Authentication Request
Client
Delegated authentication – bind request will be sent to underlying directory for processing
Custom scripting to leverage the appropriate encryption algorithm

19. Example: Proxy Authentication Back to the Right Active Directory Domain Controller in a Specific Forest
Authentication Request
VDS
Client
Authentication request forwarded to Active Directory AD
RE-USE existing users + credentials!
sAMAccountName
unicodePwd

21. Use Case: Authorization (Join)
Challenges:
Profile information exists in multiple data sources
Data sources have their own schema elements
Attributes are different and stored differently
Each source has its own schema (e.g. user – AD vs. inetOrgPerson – Sun vs. Employee table – Oracle)
Attributes
memberOf (AD)
groupOfNames (eDirectory)
posixGroup (OpenLDAP)
Inflexible schema extensions (AD)
Virtualization solves the authorization problem
Provides a common schema that all sources can map to
Aggregates profile information which provides more context about a user
Web access management products can base policy decisions on the information available in the VDS
More attributes available = more fine-grained policies possible

22. Deployment Details: Schema Extensions
Access AD attributes plus the required
extended attributes
Client
(e.g. TAM – requires schema extensions, integrating UNIX/AD – posix attributes…etc) AD
USER OBJECT
EXTUSER OBJECT
dept
memberOf
uidNumber
home directory
password
loginShell

23. Build a Complete Profile
Join – build a complete, unique profile from information in all data sources
Can base authorization
on complete profile
FullName = Laura Callahan title=Sales Manager employeeID=8 ProjectID=2019 Department=Sales
Client
First_Name = Laura Last_Name = Callahan Department = Sales EmployeeNo=8
FullName = Laura Callahan ProjectID= UserID=8
cn = Laura Callahan title=Sales Manager employeeID=8

24. Customer Implementation
Virtual Directory Role •
Central location for user authentication, roles,
and authorization
Virtualization of a single user identity across all
systems
Synchronization of real-
time application user
identity changes
Application
Web Server
SiteMinder
Web Agent
Cookie Provider ( )
Web Browser
Policy Server
App 1
User Store 4 2 3
RadiantOne
Virtual
Directory

25. Use Case: Delivering Data in Context
Challenge:
For Delegated Administration
Existing hierarchies are relatively flat – making them easier to maintain and manage.
However, this limits the usefulness of delegated administration
Delegated administration requires a hierarchy based on how you want to delegate
How does a virtualization layer deliver data in context?
Reconfigure existing directory trees to make more meaningful views for delegated administration
Based on the data available in the entries, different hierarchies are possible (e.g. based on: Country -> State -> City, Management (org chart), Job Description…etc)

26. Virtual View Based on Location
Country
State
City

27. Virtual View Based on Org Chart
Top Manager
Full Management Hierarchy

28. Virtual View Based on Role, Location and Territory

29. Use Case: Global Directory and Enterprise search
Problems:
Mergers and Acquisitions result in numerous enterprise directories/databases that require integration/aggregation
Active Directory
HR Systems
Customer databases
Often times, applications that consume data can only connect to a single directory
How does a virtualization layer help build a Global/Enterprise Directory?
Aggregate multiple data sources into a common directory namespace
No changes (to schema or data) required in the underlying directories
Fast implementation and configuration
Re-use existing data rather than rebuild a new directory where data is synchronized into.

30. Customer Implementation
Abstraction Layers 7

31. Aggregate Existing Data Sources
“Talk” to a single directory
dc=Global Directory
Client
ERP HR
Knowledge
Management
CRM
White Pages
Help Desk

32. Data Sources with Common Users (with existing common key)
With unique common key
Joins based on common key
FullName = Laura Callahan title=Sales Manager employeeID=8 ProjectID=2019 Department=Sales
First_Name = Laura Last_Name = Callahan Department = Sales EmployeeNo=8
FullName = Laura Callahan ProjectID= UserID=8
cn = Laura Callahan title=Sales Manager employeeID=8

33. Data Sources with Common Users (NO Existing Common Key)
Without unique common key
Virtualization alone cannot detect duplicate users
Requires Identity correlation and reconciliation
Matching rules to determine common users across the sources
Data Sources
Matching Rules
Global Identity Hub
Global Directory Entry
CRM
Reference/pointers
Accounting HR

34. Customer Implementation
Initial Problem 4
COI ’
s did not have an ability to reach across the disparate agencies
and networks to
find contact and profile information
As in all cases where information needed to be accessed from var
ying sources –
data
ownership, security, and privacy were the largest hurdles.

35. Customer Implementation
Approach 4
Create a unified virtual directory where it was easy to get buy
in from the disparate data
owners.
The primary ‘
selling points ’
were: –
Capability
: Users would be able to search for personal contact informatio
n across
organizations and domains, previously unavailable.
Data Ownership
: The solution allowed the owners of the disparate identity
repositories to remain the autonomous authoritative source. Rea
d only access rights
were requested to identity repositories.
Data Virtualization
: Data would not be synchronized, i.e. replicated or copied.
Synchronization would be difficult to deploy and maintain. Furt
her, a latency may
exist introducing uncertainty surrounding currency of informatio n.