Presentation on theme: "Identity and Context Virtualization The Key to Your IdM Architecture"— Presentation transcript:
1Identity and Context Virtualization The Key to Your IdM Architecture
2“Everything You Know About IdM Is Wrong” Neil McDonald, Gartner IAM Summit
3Gartner: Contextual Virtual Identity "By year-end 2009, 80 percent of organizations deploying IAM solutions will usevirtual directory technology as part of the IAM infrastructure"
4It’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”
6Customer 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
9Identity and Context Virtualization One Infrastructure: Many Services VDSDifferent Virtual Directory views for different servicesA common identity The Virtual Identity HubICS
10Top 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 DirectoryMultiple domains/forestsAuthorization (Roles, Rules, SM, RSA,TAM, Policy Server)Context are generally defined in applications that use databasesDelegated Administrationsegregation of dutiesspecialized contextual viewsGlobal/Enterprise Information Server for structured data (moving from a directory as a context server)
11Use 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 mechanismDifferent encryption of passwords and schema elements (userPassword vs. unicodePwd…etc).Existing internal user IDs, passwords in Active DirectoryExternal users credentials may be stored elsewhere (SunOne, Oracle…etc)Virtualization solves the authentication problemAggregating 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)
12Three Main Challenges Associated with the Identification (Search) Phase of the Authentication Locating the user where to search for themIf there is more than one place, the challenge becomes where to search and in which orderHaving a common representation of the user infoSchema 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
13Authentication Step 1: Identification Locate the user entry (based on who logs in)DatabasesApplicationsDirectoriesUser information spread across multiple heterogeneous sources and stored differently
14Example: Identification Challenges with Multiple Active Directory Forests/Domains VDSo=vdsou=AD Listou=AD1ou=AD2ou=AD3Active Dir Domain 1Active Dir Domain 2Active Dir Domain 3One entry point to access all Active Directory domains/forests (mount all AD domains into the virtual namespace)dc=usdc=us.corpdc=cisou=internalou=groupsou=deptou=salesou=tempsou=Adminou=Conou=salesou=mktgcn=novato_branch
15Identification: Create an Aggregated List of User Entries Aggregation/linking establish a complete list of User EntriesAll schemas are mapped to a common schemaAll users can be found/identified in the virtual namespace
16Aggregation 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 sourcesReduced sign on is possible only if an identity exists (andhas been be detected/correlated) across different security domains
17Authentication Step 2: Credentials Checking Authentication MechanismPassword encryptionsDatabasesApplicationsDirectoriesPasswords encrypted using custom algorithmPasswords encrypted using custom algorithmPasswords encrypted using SSHA
18Authentication Step 2: Credential Checking Multiple authentication mechanisms supportedAuthentication RequestClientDelegated authentication – bind request will be sent to underlying directory for processingCustom scripting to leverage the appropriate encryption algorithm
19Example: Proxy Authentication Back to the Right Active Directory Domain Controller in a Specific ForestAuthentication RequestVDSClientAuthentication request forwarded to Active DirectoryADRE-USE existing users + credentials!sAMAccountNameunicodePwd
21Use Case: Authorization (Join) Challenges:Profile information exists in multiple data sourcesData sources have their own schema elementsAttributes are different and stored differentlyEach source has its own schema (e.g. user – AD vs. inetOrgPerson – Sun vs. Employee table – Oracle)AttributesmemberOf (AD)groupOfNames (eDirectory)posixGroup (OpenLDAP)Inflexible schema extensions (AD)Virtualization solves the authorization problemProvides a common schema that all sources can map toAggregates profile information which provides more context about a userWeb access management products can base policy decisions on the information available in the VDSMore attributes available = more fine-grained policies possible
22Deployment Details: Schema Extensions Access AD attributes plus the requiredextended attributesClient(e.g. TAM – requires schema extensions, integrating UNIX/AD – posix attributes…etc)ADUSER OBJECTEXTUSER OBJECTdeptmemberOfuidNumberhome directorypasswordloginShell
23Build a Complete Profile Join – build a complete, unique profile from information in all data sourcesCan base authorizationon complete profileFullName = Laura Callahan title=Sales Manager employeeID=8 ProjectID=2019 Department=SalesClientFirst_Name = Laura Last_Name = Callahan Department = Sales EmployeeNo=8FullName = Laura Callahan ProjectID= UserID=8cn = Laura Callahan title=Sales Manager employeeID=8
24Customer Implementation Virtual Directory Role•Central location for user authentication, roles,and authorizationVirtualization of a single user identity across allsystemsSynchronization of real-time application useridentity changesApplicationWeb ServerSiteMinderWeb AgentCookie Provider()Web BrowserPolicy ServerApp1User Store423RadiantOneVirtualDirectory
25Use Case: Delivering Data in Context Challenge:For Delegated AdministrationExisting hierarchies are relatively flat – making them easier to maintain and manage.However, this limits the usefulness of delegated administrationDelegated administration requires a hierarchy based on how you want to delegateHow does a virtualization layer deliver data in context?Reconfigure existing directory trees to make more meaningful views for delegated administrationBased on the data available in the entries, different hierarchies are possible (e.g. based on: Country -> State -> City, Management (org chart), Job Description…etc)
27Virtual View Based on Org Chart Top ManagerFull Management Hierarchy
28Virtual View Based on Role, Location and Territory
29Use Case: Global Directory and Enterprise search Problems:Mergers and Acquisitions result in numerous enterprise directories/databases that require integration/aggregationActive DirectoryHR SystemsCustomer databasesOften times, applications that consume data can only connect to a single directoryHow does a virtualization layer help build a Global/Enterprise Directory?Aggregate multiple data sources into a common directory namespaceNo changes (to schema or data) required in the underlying directoriesFast implementation and configurationRe-use existing data rather than rebuild a new directory where data is synchronized into.
31Aggregate Existing Data Sources “Talk” to a single directorydc=Global DirectoryClientERPHRKnowledgeManagementCRMWhite PagesHelp Desk
32Data Sources with Common Users (with existing common key) With unique common keyJoins based on common keyFullName = Laura Callahan title=Sales Manager employeeID=8 ProjectID=2019 Department=SalesFirst_Name = Laura Last_Name = Callahan Department = Sales EmployeeNo=8FullName = Laura Callahan ProjectID= UserID=8cn = Laura Callahan title=Sales Manager employeeID=8
33Data Sources with Common Users (NO Existing Common Key) Without unique common keyVirtualization alone cannot detect duplicate usersRequires Identity correlation and reconciliationMatching rules to determine common users across the sourcesData SourcesMatching RulesGlobal Identity HubGlobal Directory EntryCRMReference/pointersAccountingHR
34Customer Implementation Initial Problem4COI’s did not have an ability to reach across the disparate agenciesand networks tofind contact and profile informationAs in all cases where information needed to be accessed from varying sources–dataownership, security, and privacy were the largest hurdles.
35Customer Implementation Approach4Create a unified virtual directory where it was easy to get buyin from the disparate dataowners.The primary‘selling points’were:–Capability: Users would be able to search for personal contact information acrossorganizations and domains, previously unavailable.Data Ownership: The solution allowed the owners of the disparate identityrepositories to remain the autonomous authoritative source. Read only access rightswere 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 mayexist introducing uncertainty surrounding currency of information.