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 iden
Trang 1This page intentionally left blank
Trang 2Oracle Directory Services
405
Trang 3406 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
Trang 4sitting 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
Trang 5408 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
■
■
■
■
Trang 6Meta-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
Trang 7410 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
■
■
■
Trang 8Access 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
Trang 9412 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
Trang 10and 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
■
■