Federated Directory Services for the connected enterprise Federated Directory Server helps overcome the challenge of distributed identity data, which is a significant hurdle to the deployment of new enterprise business solutions. Table&of&Contents& Business&challenges&and&solution&scenarios&...&2 Business&scenarios&...&2 Enterprisesecurity...2 Collaborationandsocialinteraction...3 Cloud access&provisioning...4 Mobileaccess...4 Federated&Directory&Server&...&5 Migrateorco<exist...5 Joinmultipledirectories...6 Enrichwithdatafromothersources...6 SelectivewriteBackofchangestotheoriginalsource...6 Federateauthenticationbacktooriginalsource...7 Performance&characteristics&...&7 Conclusion&...&8
Business&challenges&and&solution&scenarios&& Therequirementsareclear: allusersmustbeabletologinthroughoneserver and find information about everybody in one place. Rip and replace is not an option.ontheotherhand,anysignificantchangetotheexistinginfrastructureis notacceptableeither.somethingneedstogive. Identity data is a critical component of the connected enterprise. This is information about employees, customers, contractors, and business partners. It is essential for focus areas such as enterprise security, collaboration and social interaction, cloud based solutions, and business compliance. Each of these realms introduces challenges and requirements of their own,andthey will be discussedfurtheroninthispaper. Althoughnotasurprise,itisstillcuriousthatthiscriticalinformationisstoredin several places, but not in the same format, and not even consistent in data content.additionally,itissometimesmanagedunderdifferentjurisdictionswith unique processes and compliance requirements. Finally the systems that store this information have varying degrees of technical availability, scalability, data reliabilityandsecuritypolicy. IBMFederated Directory Server bridgesthissetofchallenges.itisbuiltona world leading, market proven,and massively scalable directory service. Yet it integratesrightbackintofragileenvironmentsthathaveimportantdata,though they might not for various reasons be ready to directly support the new requirementsoftheplannedenterprisesolutions. Business&scenarios& Thebusinessareasshownbelowhavehighvisibilityinmostenterprises.They providethebackgroundforadiscussiononhowfederateddirectoryservercan rapidlyhelptodeployenterprise solutionsinthesecontexts. Enterprise&security& Security is an ever more important component of the enterprise infrastructure. However, it is common that identity data is fragmented across multiple LDAP directories or other resources. This complicates deployment of services
suchassinglesign<on 1 thatuseauthenticationserverstoverifythatusernames andpasswordsarevalid.forexample:& a. Forcomplianceorcounter<threatreasons,anorganizationcouldmandate thatallusersauthenticateusingtheiremailaddressoremployeenumber. This is difficult to implement if there is no standard for login names acrosstheenterprisedirectories. b. Employeesneedtointeractwithcustomerswhenloggingintoexternally facing IT systems such as enterprise content systems or social software like IBM Connections 2. For security reasons the existing enterprise directoriescannotbeusedtoauthenticateusersinthissituation. There are other common problems such as that enterprise applications only beingableto connect to a single corporate LDAP directory for authentication purposes. However, people can exist in several directories, and the naming structure for authentication credentials can vary across the systems. Also, certaindirectoriesmightcontainpeopleandgroupsthatarenottobesurfaced totheenterpriselevel. Collaboration&and&social&interaction& Thefirstitemontheagendawhenplanningsocialsoftwareinanenterpriseisto address any authentication challenges as described in the previous section. However, once security has been addressed, thenextstageis todesigna rich environment for users. Social software is about content and context, which means that information about people needs to be available and visible. For example, phone numbers, organizational and geographical location, and similar contentthatmayexistinothersystemsintheenterprise. 1 IBMSecurityAccessManagement: ISAM:http://www.ibm.com/software/products/en/access<mgr<web ESSO:http://www.ibm.com/software/products/en/access<mgr<esso 2 http://www<01.ibm.com/software/lotus/
Suchinformationrichnessisusuallynotavailableinexistingdirectories,sothe data must be brought in, merged, correlated and cleaned before this added content can be made available to the social software. A final point is that this informationneedstobeavailablefast,andsometimesglobally,whichmeansthat dependence on the systems where the data originated should be avoided becausetheymightnotbedesignedforthehigherperformanceandavailability requirements. Cloud& &access&&&provisioning&& Cloud is a broad topic. Therefore a few scenarios are used to illustrate where FederatedDirectoryServercansimplifydeploymentandusageofnewservices. The core problem from an identity perspective is that the cloud<based systems do not have access to the existing authentication services. Depending on the situation,thiscanbeaddressedby a. Synchronizing user information between the enterprise and the cloud environments. Federated Directory Server supports the SCIM protocol, which is a commonly supported protocol for user provisioning. For example, any changes in local Active Directories can be synchronized acrosstoacloudidentityservice. b. Providing the cloud environment with access to the enterprise authentication services. This can work well in a private cloud scenario where the new cloud infrastructure is within existing enterprise infrastructure. c. UsefederationserviceslikeIBMFederatedIdentityManager 3,whichlets enterpriseusersaccesscloudserviceswithoutsynchronization. FederatedDirectoryServerisasolidfoundationforprivate,hybrid,orpublic cloudprojectswhenexistingusersneedaccesstonewservices. Mobile&access& Accessfrommobiledevicesinsidetheenterpriseisinmanywayssimilartothat fromworkstations.however,onceoutsidetheenterpriseperimeter,themobile unitsmustfirstaccesstheinfrastructurethroughavpnserviceorothermobile access management service 4. These services struggle with the same issues as described in the Enterprise security section above in that there might be multipleinternaldirectorieswhereusersaremanaged.furthermore,theactual structure of the user credentials is possibly different in the systems as well, making it challenging to consolidate for mobile access. For example, on one systemlogginginmightrequireausernamesuchas anne_p@marketing,while onanotherserveritmightbe AnneParks/Marketing. Federated Directory Server can provide a single name space to the mobile gatewayssothatallusersmayusethesametypeoflogin,suchasemailaddress 3 http://www<03.ibm.com/software/products/us/en/federated<identity<mgr/ 4 IBMSecurityAccessManagerforCloudandMobile:http://www< 03.ibm.com/software/products/us/en/samcm/
or employee number, yet still be authenticated against their home directory in linewiththewaythatauthenticationiscurrentlyconfigured. Federated&Directory&Server& Federated Directory Server delivers a number of capabilities that allow an organization to address the above business scenarios. It is a foundation for enterprise security and identity visibility that combines performance, global scalability, and government class security with deep integration to legacy directoryservices.inthiswayanorganizationcankeepwhatisalreadyinplace, yetextendtheuseoftheinformationtosupportnewrequirements. The deployment scenarios illustrated below are examples that will be used to discussthecapabilitiesintheproduct.thesescenariosdonotexcludeeachother, andaredescribedthiswaytosimplifyeachusecaseratherthanlistallindividual capabilities. Migrate&or&coFexist& Whentransitioningfromonedirectorytoanotheritisusuallynotenoughtojust migrate the data since business will be ongoing until the move is complete. Sometimes both directories need to stay in place for some time, which introducesanumberoftechnicalconsiderations. a. Mustchangesintheoriginaldirectoryimmediatelybepropagatedtothe newdirectory? b. Canoriginaldatabeusedasis,ormustitbecheckedandpossiblycleaned orotherwisemodifiedtoconformtoenterprisestandards? c. Should users get new passwords, or should login to the new directory resultinauthenticationbacktotheoriginaldirectory? d. If attributes are modified in the new directory, should these changes be writtenbacktotheoriginaldirectory? e. Should the directory hierarchy be mirrored in the new directory or shouldthedatastructurebesimplified?
f. Shouldgroupsalsobesynchronized? Federated Directory Server supports all of these scenarios, providing an organization with a significant amount of flexibility when planning a directory migrationorco<existenceproject. Join&multiple&directories& Dealingwithmultipledirectoriesisnotverydifferentfromthepreviousscenario. WithFederatedDirectoryServer,anynumberofdirectoriescanbeintegratedat the same time. All of the capabilities mentioned above work as expected with multipledirectories. Federated Directory Server additionally helps consolidate the user names that are used to log in. The existing directories possibly have different naming structures, which can lead to confusion in the organization. FDS allows you to choose a common attribute to identify users, transparently converting login credentials to the values expected by the existing directories. The next section will describe how data from other sources can be pulled into the user profiles andthenbeusedtoidentifyuserswhentheylogin. Enrich&with&data&from&other&sources& Notonlydoesidentitydatathatisstoredinmultipledirectoriesneedtoappear asifitiscomingfromthesameplace,butthisdatamightneedtobecombined withinformationfromothertypesofsystemsanddatastoresaswell.infdsthis is called joining data from multiple sources. For example, there might be additional organization data in an Human Resources (HR) system, or other attributesinadatabasethatneedtobeavailableinthenewdirectory.fdscan join in data from any number of sources because the underlying technology is basedondirectoryintegrator.thisincludesaccessingwebservices,rest<based systems, SQL databases, and many other out<of<the<box sources, as well as entirelycustomsourcesbyexploitingthepowerofdirectoryintegrator. Selective&writeBack&of&changes&to&the&original&source& Changes in Security Directory Server (SDS) can be pushed back to the source systems.forexample,usersmightbeallowedtomodifytheirhomeaddressand telephone number, which will be written back to Active Directory so that the Microsoft environment can benefit from changes created by the new systems. Thisprovidesanadditionallayerofsecurity,mitigatingtheneedforsettingup advanced security models to restrict direct access to the existing directories. Part of the vision for FDS has been to insulate and extend the existing data environments, to reduce the risk of exposing them directly to new enterprise servicesthattheywerenotdesignedtohandle.
Federate&authentication&back&to&original&source& Password synchronization is a thing of the past 5. Users and passwords can continuetobemanagedthewaytheycurrentlyare,eveninmultiplesystems.if desired,theycanautomaticallybetransferredtosecuritydirectoryserver(sds) at the appropriate time if the existing directory server needs to be sunset for authentication purposes. It is even possible to let users log into SDS using a differentlogincredential(suchastheiremailaddressoremployeenumber),and have SDS automatically translate that to the correct user name when checking thepasswordintheexistingdirectories. Performance&characteristics& The hybrid integration architecture of FDS results in significant performance characteristics. Firstofall,IBMSecurityDirectoryServer(SDS)istheLDAPengineinFDS.SDSis ahighlyscalable,veryreliableandhighperformanceldapdirectoryserver.for large environments, SDS can replicate data to provide maximum speed in local infrastructures across the world. Therefore, existing data located in an identity silocanbeintegratedwithricherdatafromothersystems,andthenpropagated throughsdstomakeinformationavailableathighspeed. Although part of the same argument as above, it s worth pointing out that existing identity sources might not be designed or managed in a way that is suitable for real<time integration with new enterprise services. FDS represents an insulateandextend approachwherechangesarepulled onlyonce from existing systems and after that are accessed only from SDS. It is therefore possible to deliver world<class performance independent of the speed and availabilityofexistingsystems. 5 Passwords are usually one<way encrypted. This means that you can ask a server is this the correct password for this user, but cannot ask what is the password for this user. As a result passwords generally cannot be copied betweensystemsunlesstheysharetheexactsameencryptionalgorithm.
Compared to a traditional virtual directory approach, the FDS approach ensuresthatdataisavailableathighspeedaccessbeforeitisrequestedbyauser. And finally, all data can be aggregated, cleaned and harmonized to a common formatbeforeitisaccessed.themorecomplexthedataharmonization,themore costly it is to perform this in real<time and still maintain an acceptable level of performance. Conclusion& Federated Directory Server provides a new range of options for identity infrastructures. Existing directories can be seamlessly integrated into new directory services that scale in a manner that previously was not possible. Existingusermanagementprocessescanstayinplace,andcanevenbeapplied tonewdirectorieswhendesired. AsFDSisbasedontheDirectoryIntegratortechnology,itcanbecustomizedto practicallyanyscenariotohandlethespecificrequirementsoforganizationsthat haveuniquetechnicalchallenges. With FDS, distributed identity silos can be brought together so that the enterprisecanexposeasingle,logical,rich,andstructuredinterfacetonewand existingenterpriseapplications.