Identity and Context Virtualization The Key to Your IdM Architecture
Dec 14, 2015
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"
“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”
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
Customer Implementation
Customer Implementation
Identity Architecture
Identity Management Service
IdM Access Services
Authentication User Object Data AccessAuthorization
ProvisioningEngineVirtual Directory
Enterprise Directory
MetaDirectoryAuthorization Manager
Authoritative Sources
Network Operating System
Active DirectoryFRB
Groupware / EmailNetwork
Operating SystemActive Directory
Board
Mainframe
HR Human Capital
Management System
Identity Provisioning
Virtualization Layer
Identity and Context VirtualizationOne Infrastructure: Many Services
VDS
VDS
VDS
VDS
VDS
Different Virtual Directory views for different services
A common identityThe Virtual Identity Hub
ICS
Top 4 Common Use Cases for Identity and Context Virtualization
1. Authentication (WAM, Portal, SM, TAM, RSA, Ping)
a. Integrating identities: Internal vs. External, Employees/Customers…etc…b. The challenges and opportunities brought by Active Directory
• Multiple domains/forests
2. Authorization (Roles, Rules, SM, RSA,TAM, Policy Server)
a. The challenges and opportunities brought by Active Directoryb. Context are generally defined in applications that use databases
3. Delegated Administrationa. segregation of duties b. specialized contextual views
4. Global/Enterprise Information Server for structured data (moving from a directory as a context server)
Use Case: Authentication(Identity Union)
• Challenges:1. 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)
2. 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)
Three Main Challenges Associated with the Identification (Search) Phase of the Authentication
1. 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
2. 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)
3. Distinguishing between the different identifiers for the same person…. • LCallahan, LauraC…
Authentication Step 1: Identification
• Locate the user entry (based on who logs in)
Databases DirectoriesApplications
User information spread across multiple heterogeneous sources and stored differently
Example: Identification Challenges with Multiple Active Directory Forests/Domains
o=vds
ou=AD List
ou=AD3ou=AD2ou=AD1
dc=us
ou=internal
cn=novato_branch
Active Dir Domain 1
ou=sales ou=temps
dc=us.corp
ou=groups
Active Dir Domain 2
ou=Admin ou=Con
dc=cis
ou=dept
Active Dir Domain 3
ou=sales ou=mktg
VDS
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
Aggregation vs. Integration: Union, Intersection (correlation where needed)
Reduced sign on is possible only if an identity exists (and has been be detected/correlated) across different security domains
Authentication Step 2: Credentials Checking
• Authentication Mechanism• Password encryptions
Databases DirectoriesApplications
Passwords encrypted using custom algorithm
Passwords encrypted using
SSHA
Passwords encrypted using custom algorithm
Authentication Step 2: Credential Checking
• Multiple authentication mechanisms supported
Delegated authentication – bind request will be sent to underlying directory for processing
Custom scripting to leverage the appropriate encryption algorithm
Client
Authentication Request
Example: Proxy Authentication Back to the Right Active Directory Domain Controller in a Specific Forest
Client
Authentication Request
AD
unicodePwd
sAMAccountName
Authentication request forwarded to Active Directory
VDS
RE-USE existing users +
credentials!
Fifth Third Bank | All Rights Reserved7
CRM Mobius 5/3 Direct 53.comRemote
WireHR Direct Other Apps
Application Layer
Directory Adaptor / Common Interfaces RSA ClearTrust Web Access Management (WAM)
Enterprise Directory (Sun)
VDS (Radiant)
Provisioning Engine (BMC)
RAFT Top SecretAD Data WarehousePrimary Identity Store
Workflow / Provisioning
Application Access Points
Identity Management (IdM) Technology Stack
Virtual Directory Services (VDS) Provisioning Engine
Enterprise Directory (ED)
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
Deployment Details: Schema Extensions
USER OBJECT
email password
memberOfdept
EXTUSER OBJECT
loginShell
uidNumber home directory
AD
Client
(e.g. TAM – requires schema extensions, integrating UNIX/AD – posix attributes…etc)
Access AD attributes plus the required extended attributes
Build a Complete Profile
• Join – build a complete, unique profile from information in all data sources
cn = Laura Callahan [email protected] title=Sales Manager employeeID=8
FullName = Laura Callahan ProjectID=2019 UserID=8
First_Name = Laura Last_Name = Callahan Department = Sales EmployeeNo=8
FullName = Laura Callahan [email protected] title=Sales Manager employeeID=8 ProjectID=2019 Department=Sales
Client
Can base authorization on complete profile
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
SiteMinderWeb Agent
SiteMinderCookie Provider
(Web Agent)
Web Browser
SiteMinderPolicy Server
App1 User Store
App4 User Store
App2 User Store
App3 User Store
RadiantOneVirtual
Directory
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)
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.
Aggregate Existing Data Sources
Help DeskERP HR Knowledge
Management White PagesCRM
Client
“Talk” to a single directorydc=Global Directory
Data Sources with Common Users (with existing common key)
• With unique common key• Joins based on common key
cn = Laura Callahan [email protected] title=Sales Manager employeeID=8
FullName = Laura Callahan ProjectID=2019 UserID=8
First_Name = Laura Last_Name = Callahan Department = Sales EmployeeNo=8
FullName = Laura Callahan [email protected] title=Sales Manager employeeID=8 ProjectID=2019 Department=Sales
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
HR
Accounting
CRM
Global Identity Hub
Reference/pointers
Data Sources Matching Rules Global Directory Entry
Customer Implementation
Initial ProblemCOI’ 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 varying sources – data ownership, security, and privacy were the largest hurdles.
Customer Implementation
Approach 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 information across organizations and domains, previously unavailable.
– Data Ownership : The solution allowed the owners of the disparate identity repositories to remain the autonomous authoritative source. Read 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. Further, a latency may exist introducing uncertainty surrounding currency of information.