Capgemini Oracle Blog

Capgemini Oracle Blog

Opinions expressed on this blog reflect the writer’s views and not the position of the Capgemini Group

Merging multiple directories and databases to one Virtual Directory

Categories : SecurityTechnical

If we look at many organizations today we note that they originate from many mergers and acquisitions from the past. While these type of companies present themselves as one company to the outside world their organization, processes and IT are still very diverse and fragmented. With this diversity the problem often comes along that they do not have one single Identity Administration for example for employees or customers. Instead they have multiple administrations including all sorts of supporting applications and technology throughout the organization. Not having such a single truth poses some tremendous challenges. Especially when a new organization wide application is introduced or when you want to maintain descent security policies. To make matters even worse creating a single truth can be even harder. For example the amount of effort to clean data and to migrate data to one single application can be costly (not even mentioning the impact on the processes that manage this data). I was pleasantly surprised that Oracle provides a nice product to solve this issue with much less effort needed compared to implementing one single administration: Oracle Virtual Directory, or in short OVD. OVD can create a single virtual LDAP based directory by aggregating multiple directories and/or other sources such as databases in to one. It can even help joining data for example if the name of an employee is stored in application A but his or her role in database B. OVD hides the complexity of data location, format, and technology diversity from client applications. It handles the details of how to establish connections and protocols between different data sources. It makes many sources appear to be one directory in much the same ways that routers make the entire world appear like it’s on your local network. OVD basically follows the strategy of keeping existing administrations as they are and virtually joining them. This helps extending your existing infrastructure investments and can have a minimal impact on existing administrative processes. You can also avoid difficult synchronization issues and, if you want, create one new point of entry for managing identities. For example this can help improve the process of people joining and leaving the organization. A couple of weeks ago I decided to do some more research into the product and verify my enthusiasm for OVD. I simulated the well-known problem that I want to create one single virtual directory with all identities coming from multiple directories for authentication purposes. The implementation so far went great, however, some challenges were already met that put my enthusiasm to the test. Two challenges I would like to discuss here. One challenge I have is that OVD uses the concept of adapters. For each source you want to aggregate into your virtual directory you need to configure an adapter that is able to connect to the source. For example a Database adapter is provided for connecting to relational databases. This may sound very cool but be advised that Oracle is cautious in supporting all different sources and technologies. While technically almost every source can be incorporated, getting support on your source requires a visit to the support documentation of OVD! The other challenge is creating the root entries of your virtual directory. The root DN (the first entries of your directory) of your new virtual directory is often something such as dc=mycompany,dc=com. It is a common practice to create these first two entries implementing the local store adapter. This adapter stores the entries in a local data store on the OVD server itself. If you do not properly configure objectClasses for these root entries your entire virtual directory might be unreadable for application clients. The best way to solve this challenge is to create two local store adapters for each entry. Make sure you check the “create the suffix” checkbox when you configure the adapters. This causes the configuration wizard to ask for your preferred objectClass. Choose the domain objectClass for both entries and your virtual directory will be accessible. Over the next few weeks new challenges will likely arise with this elaboration. Via this blog I will keep you posted about my enthusiasm level. Stay tuned! Bart Kooijman, Java architect, Security specialist

About the author

Léon Smiers

Leave a comment

Your email address will not be published. Required fields are marked *.