This page intentionally left blank CHAPTER 10 Oracle Directory Services 405 406 Part III: Identity Management his chapter focuses on Oracle’s approach to solving the challenge of providing fast, reliable, and scalable repository for storing, organizing, and retrieving identity and access information. Oracle’s directory strategy relies on the Lightweight Directory Access Protocol (LDAP) standard as the primary interface for exchanging and managing the directory data. The original point of creating the LDAP server was to have an information repository highly optimized for reading data. While Oracle has certainly made its LDAP servers much more capable in handling large transaction (read-write) volumes, optimized reads continues to be the basic driver for using an LDAP server. Oracle offers two directory products—Oracle Internet Directory (OID) and Oracle Virtual Directory (OVD)—that represent two unique but complementary solutions for managing and exchanging identity and access information via LDAP. In this chapter, we will review these products from the perspective of managing, storing, organizing, and retrieving identity data. Instead of being too focused on the LDAP standard or generic directory design, we focus on how to apply these Oracle products to solve common challenges in this space. Identity Management and the LDAP Directory The user directory is a bedrock entity of identity management for storing, managing, organizing, and sharing identity information with applications where those identities are access controlled. LDAP has become the de facto standard in interacting with directory data and is therefore a core part of any identity management product strategy, including that of Oracle. While LDAP provides a standard information access interface and protocol, identity management faces a major issue with the proliferation of directory systems of different types, different data models, and different naming conventions. For example, it is common to see Active Directory being used for the Windows authentication, whereas OID is being used for Oracle databases and web applications. The consequence of having multiple LDAP servers is that the same human user has two, often disparate, records in two separate LDAP repositories. Such fragmented repositories drove Oracle’s decision to acquire OctetString in 2005 to add a virtual directory offering for enterprises with a specific need for rationalizing information across multiple physical repositories of identity information. Today, Oracle caters to a wider set of directory needs by offering OID focused on the physical storage and management, while OVD is focused on tackling integrating data from multiple directories and databases in real-time, to provide applications a single logical LDAP server to query user information pertaining to identity management. Oracle Internet Directory OID is a fully compliant LDAP v3 directory server used primarily for storing identity and access information. OID is also often used for managing database instance names and as a lookup service for DBAs who regularly log into different databases using SQL clients. If you already have a basic understanding of LDAP servers, you’ll find OID a fairly simple product to understand. The characteristic that separates OID from other directories is its ability to scale to handle very large volumes of identity information quickly, often upwards of 100 million users per implementation. A number of the world’s largest LDAP servers use OID as their underlying LDAP repository. The reason it scales in such large numbers is because underneath its covers, OID is an application T Chapter 10: Oracle Directory Services 407 sitting on top of the highly scalable Oracle Database server. It inherits all of Oracle Database’s performance characteristics and can be tuned to scale just like any Oracle Database application. OID Architecture As demonstrated in Figure 10-1, the runtime execution of OID flows through three key layers of abstraction: LDAP listeners, LDAP-to-relational mapping, and the backend Oracle Database metadata repository. The listener and mapping layers of OID are middleware components written in Java/J2EE and managed as a component of the Oracle Application Server environment. The backend repository is a specialized metadata repository with a predefined database schema and data model for efficient LDAP data transactions. A number of packaged configurations of OID allow it to scale rapidly and provide a highly available repository for an enterprise. One such configuration might be leveraging the Oracle Real Application Cluster (RAC) environment for managing the directory metadata. In addition, to optimize the OID server for data reads, you can apply tuning techniques, both at the LDAP server level (for example, adding indexes for LDAP attributes that are frequently used for querying information) and at the database level (for example, tuning the basic kernel parameters and the database I/O parameters). For specific database tuning tips, read Thomas Kyte’s Effective Oracle by Design (McGraw-Hill Professional, 2003). FIGURE 10-1 Layered view of OID 408 Part III: Identity Management OID Synchronizations One of the key challenges we face today with directories and their deployments is finding the right balance between performance and manageability. We usually need our directories to return queries with subsecond round-trip times. Since the applications rely on the directory constantly to authorize users for access, low latency response is a must. Two key challenges are apparent in terms of directory data management: Distribution Since users are often spread all across the country and, increasingly, the globe, a major challenge for directories is to optimize the distance of the directory information from the user. For example, it is very inefficient to authenticate against a centralized LDAP server in the United States when the users in the Tokyo sales office are trying to access the local customer database application. Consistency Due to proliferation of applications and systems maintaining identity information, it becomes more difficult to keep it all consistent across systems. Inconsistency in the identity data is a major issue from a usability perspective and also a management pain since administrators need to rationalize disparate data records for the same human user. These challenges have led to the need for directory synchronization, where the core principle is to place the right information in the right location to optimize directory performance, information consistency, and manageability. Several techniques are available for achieving these principles in OID. Replication Directory replication is one solution to the cross-enterprise data integrity challenge where data is replicated across two or more LDAP directories. With OID, replication happens at the database level where the replication processes move the LDAP information from one OID database to the other. Replication is an efficient process for synchronizing large loads of changes from one OID server to another. Keep in mind, however, that replication is not a heterogeneous solution for synchronizing and supports exchanging data only between OID servers. It requires that the following characteristics of the directory be the same: Directory server type Oracle Internet Directory servers of the same major version (such as 9.x, 10.x, and so on) Namespace The hierarchy and namespace in the directory information tree design is identical As mentioned, this is a recommended approach when the enterprise has standardized on the OID platform and has physical deployments of that standard OID server across geographies serving different populations of users. If you want to implement this kind of replication, the OID administration guide is a good tutorial on the exact configuration steps for setting up replication. Directory Integration Platform OID offers an embedded meta-directory solution, called Directory Integration Platform (DIP), for synchronizing identity and access data between OID and other LDAP directories or non-LDAP repositories. ■ ■ ■ ■ Chapter 10: Oracle Directory Services 409 NOTE Meta-directory is an approach to synchronize directory information by physically moving information among multiple physical repositories. Unlike the replication approach, meta-directory solutions can integrate heterogeneous LDAP and non-LDAP servers (such as OID– Active Directory, OID–Database Tables, and so on) with different information formats (such as asymmetric namespaces, different LDAP schema and naming conventions, and so on). DIP supports OID and non-OID systems, such as Active Directory, Novell eDirectory, and SunOne, as well as relational tables in Oracle databases. As discussed in Chapter 8, meta-directory solutions such as DIP are usually leveraged for low-level LDAP object synchronization such as user attributes like passwords and group memberships. Configuring your OID for DIP is adequately covered in the “OID Integration Guide” in the “Directory Integration” section. Setting up a single LDAP for DIP should take no more than a few hours, involving the following high-level steps: 1. Choose a directory synchronization profile that is a predefined template for the different supported systems (such as Active Directory, SunOne and Oracle Relational Database Tables, and so on). For a full list, refer to the “OID Integration Guide.” 2. Set up the server connection from the master OID server to the external repository. 3. Set up the namespace and attribute mapping from the source to the destination. 4. Configure the synchronization behavior (such as synchronization frequency, initial information bootstrapping policies, and so on). While good for certain architectural requirements, directory synchronization has its down side, as discussed in Chapter 8. It is a form of Point-to-Point (P2P) integration, so as the number of systems needing synchronization increase, the effort to manage and maintain these P2P integrations also increase in near linear terms. As a rule of thumb, if you have more than five P2P integrations, you might want to consider alternative integration strategies that lower your management efforts. One such alternative offered by Oracle since 2005, with the introduction of its virtual directory product, is the concept of directory virtualization. Directory Virtualization and Oracle Virtual Directory Ten years ago, when we didn’t have so many online travel web sites like Expedia and Priceline, we used travel agents. The travel agent’s job was to serve as a proxy between a potential traveler and the airline carrier selling tickets. The traveler could give the travel agent a set of travel parameters (destinations, dates, and so on), and the agent would find the best deal based on those parameters. Alternatively, the travel agent could also create a predefined menu of destination choices and ticket prices from which the traveler could choose. In either scenario, the tickets could come from any carrier (United, American, Lufthansa, Singapore Airlines, and so on), yet the traveler is dealing with only one entity—the travel agent. Directory virtualization is not too different from this travel agent concept. A virtual directory, such as OVD, acts as that single travel agent for any application requesting specific LDAP objects and attributes or simply looking to browse the LDAP tree. 410 Part III: Identity Management Directory virtualization is emerging as a far more efficient alternative to directory synchronization because, unlike replication and meta-directory technologies, virtual directory products such as OVD do not physically move data between systems. Instead, they rationalize and unify data in real time when an application makes the request. OVD follows a composite access pattern whereby all physical sources are abstracted and “virtualized” as a single LDAP directory. This approach allows the directory architecture to benefit from the following: Loose coupling A virtual directory decouples LDAP clients from the physical directory, allowing for changes to the underlying repositories without impacting the LDAP clients. Flexible control of data Allows information to be integrated and joined together without removing control from current administrators of the different repositories. Information semantics normalization Allows identity information semantics to be normalized across the enterprise. Its data transformation capabilities allow actual physical formats and structures to be mapped to a single unified and normalized data format and definition across the enterprise. Keep in mind that physical data consolidation is still a good idea and can save maintenance and administration dollars over the long term. However, in some cases, multiple directories are maintained due to product dependency issues or when organizations want to maintain control over their own identity information. Therefore, a virtual directory gives you the flexibility to adapt to those decisions without necessarily compromising your LDAP design principle of having a single logical place for querying identity data. OVD 101 Oracle Virtual Directory functions much like a database view. In a database view, data from many backend tables and other sources are joined and presented as a single “virtual table” (aka view) to the end user. In a virtual directory, identity data residing in OID, Active Directory, and custom applications can be joined together, at runtime, and presented to the LDAP client as a single LDAP user profile. This is a major advantage over using a meta-directory approach since the information integration is happening only at runtime and doesn’t require that the data be moved and updated in systems prior to any application request for the identity profile. OVD is not meant to replace your existing LDAP servers and other identity repositories, because it has no concept of identity data storage. It does provide some simple ways of storing basic identity attributes, but those types of storage are not meant to replace mass data storage provided by products such as OID. Instead, OVD focuses on the problems around information aggregation and rationalization to present a unified view of data from multiple sources of data (that is, LDAP servers, databases, and so on) to LDAP clients. OVD Architecture Before setting up OVD, you need to know architecturally where it resides and how it participates in a typical LDAP request. Figure 10-2 illustrates the end-to-end flow of how an application is access controlled using identity information originating from multiple backend repositories but flowing through a single virtualized LDAP interface to the access controller. ■ ■ ■ Chapter 10: Oracle Directory Services 411 NOTE Access Controller represents a component in any identity management architecture that is responsible for gathering all the necessary information about access policies and making the decision, on a per-request basis, of whether to allow a user to take a certain action on a particular resource. In Chapter 8, we discussed Oracle Access Manager and Oracle Entitlement Server, which can be characterized as access controllers. As shown in Figure 10-2, the access controller component (the engine that decides who should and should not access resources) sits in between OVD and the applications. Access controllers can also leverage alternative communication protocols to read the directory data using XML-based formats, such as Directory Services Markup Language (DSML) and HTTP-based communication protocols. The approach of exposing directory APIs as web services is becoming more popular as enterprises are moving toward service-oriented information access architectures. The point of this shift is to make all enterprise information (including identity information) accessible to the consumer applications over a standard integration platform aimed to make it quick and easy for application integration. OVD Architectural Layers As implied by Figure 10-3, the core competency of OVD resides in its ability to apply rules to the physical data and change the presentation of that data to the LDAP client. FIGURE 10-2 OVD in the enterprise 412 Part III: Identity Management Performing this kind of on-demand transformation and unification of fragmented data requires that the responsibility be split into three specific layers: Listener Interface Allows the OVD server to share information over multiple communication protocols (such as LDAP or HTTP) and networking choices (such as ports, SSL, and so on). Rules and Mapping This layer manages the rules and mappings for executing the logic to transform information from the backend repository to the frontend consumer. Consider this the OVD “brain,” where you can perform pre- and post-processing of identity information coming from the LDAP servers. In addition to the standard mapping rules and procedures, you can also write any custom code in Python to configure OVD to execute any pre- or post-processing logic that you want executed during an LDAP call. (For example, if I have a policy for which I do not want to share a user’s location attribute if he or she belongs to the “Secret” department, I could write and register a simple Python procedure as part of the OVD server, where I make that check and nullify all the location attributes for those users in the “Secret” department.) The Python-based framework in OVD is extremely powerful and can be used for nearly any transformation, verification, or audit type requirement around LDAP information access. Adapter This layer manages the integration configuration from the OVD server to the backend repositories or other adapters. Many types of adapters have specific setup ■ ■ ■ FIGURE 10-3 Information access to and from Oracle Virtual Directory Chapter 10: Oracle Directory Services 413 and configuration patterns depending on what they are connecting to and what type of information they expect. An adapter is responsible for maintaining two types of configuration: The information on how to communicate with the backend identity data source (server host names, ports, protocols, namespaces, and so on) A set of join rules and mappings that map the virtual directory tree and definition to the structure and definition of the data in the actual sources OVD Applied By now, you should understand Oracle Virtual Directory’s architecture and the purpose it serves for solving directory integration challenges without physically synchronizing information. In this section, we work through some common implementation scenarios to give you some more practical knowledge of how to apply OVD in specific directory integration scenarios. The central objective from all the implementation scenarios still remains the same: creating a single unified view of an identity across the enterprise. OVD Installation Three key components are involved in installing an OVD: OVD Server, OVD Admin Server, and OVD Manager. The OVD Server component acts as the LDAP process where applications and other LDAP clients connect for directory information. The OVD Admin Server is an administration component that manages all the configurations in the OVD Server. The OVD Manager is a desktop application used by the directory administrator and developers to configure OVD. When you have a fresh, new install, you need to start the Admin Server and then connect into the Admin Server using the OVD Manager application. Refer to the specific steps of installing the OVD product for your specific O/S platform in the OVD installation guide that comes with the software. This section is meant to give you a quick understanding of what is installed and why. Creating a New OVD Server We assume that you now have a working OVD install with a running Admin Server. Now you can start configuring the virtual LDAP server with which applications and clients will interact. All server configurations are performed using the Oracle Virtual Directory Manager (a desktop application that comes with the product). To set up a new OVD server for your enterprise, start the OVD Manager client and follow these steps: 1. Create a directory project for storing all server configurations. 2. Create a Virtual Directory Server under the project and specify the relevant information (name, port, hostname, and so on) for your environment (as shown in Figure 10-4). This step also requires you to verify your OVD administration server credentials, which should have been set up during installation of the software. If you installed the OVD Admin Server (during the installation process) to be listening on a non-SSL port, you do not need to verify the SSL connection and accept the trusted certificate. However, it is a best practice to run the Admin Server over SSL. At this stage, you are now ready to start integrating OVD with your backend physical repositories. ■ ■ . mapping, and the backend Oracle Database metadata repository. The listener and mapping layers of OID are middleware components written in Java/J2EE and managed as a component of the Oracle Application. application T Chapter 10: Oracle Directory Services 407 sitting on top of the highly scalable Oracle Database server. It inherits all of Oracle Database s performance characteristics and can be tuned. information) and at the database level (for example, tuning the basic kernel parameters and the database I/O parameters). For specific database tuning tips, read Thomas Kyte’s Effective Oracle by