| Oracle® Fusion Middleware Administrator's Guide for Oracle Virtual Directory 11g Release 1 (11.1.1) Part Number E10046-06 |
|
|
PDF · Mobi · ePub |
| Oracle® Fusion Middleware Administrator's Guide for Oracle Virtual Directory 11g Release 1 (11.1.1) Part Number E10046-06 |
|
|
PDF · Mobi · ePub |
This chapter introduces you to Oracle Virtual Directory, its services and architecture, and includes the following topics
This topic provides an introduction to Oracle Virtual Directory and contains the following sections:
Welcome to Oracle Virtual Directory, an LDAP version 3 enabled service that provides virtualized abstraction of one or more enterprise data sources into a single directory view. Oracle Virtual Directory provides the ability to integrate LDAP-aware applications into diverse directory environments while minimizing or eliminating the need to change either the infrastructure or the applications. Oracle Virtual Directory supports a diverse set of clients, such as Web Applications and portals, and it can connect to directories, databases, and Web Services as shown in Figure 1-1.
Figure 1-2 shows an example of an enterprise application used by all employees in a company. The application accesses directory information from three different sources and each contains a separate population of users, which is typical for many organizations due to corporate structure. For example, the Active Directory repositories contain only internal employee users, the single enterprise directory contains users from a different corporate division or business partner, and another set of users, such as external contractors, is contained in a relational database. As shown in the figure, Oracle Virtual Directory can be deployed to bring together the identity information from all three sources.
Oracle Virtual Directory hides the complexity of data location, format, and protocol from client applications, similar to a TCP/IP Internet network design based on switches and routers. Switches and routers handle the details of how to establish connections and protocols between different addresses on the network. Oracle Virtual Directory makes many directories appear to be one local repository in much the same ways that routers make the entire world appear like it's on your local network.
The following is a list of some of Oracle Virtual Directory's key features:
Product Features
LDAPv2/v3 support
DSMLv2/SOAP support
HTTP/XSLT Gateway support
Low-cost configuration and maintenance
Globalization features such as multi-byte character support and localized language translations
Encryption and Strong Authentication with TLSv1 and SSLv3 support
Can be deployed to function as a directory Proxy and Firewall
Extremely small memory and hardware requirements
Available on any platform where Java is supported
Configurable Fail-Over and Intelligent Load-Balancing at the LDAP operation level
Granular Access Controls based on IETF's Access Control Implementation Internet Draft
Support for access to JNDI compliant directories and JDBC compliant databases
Dynamic mapping of information and schema in multiple directories
Intelligent Routing of LDAP Queries
Denial of Service protection
Overlapped namespace handling
Multiple types of adapters for various deployments
Extensible meta directory-like dynamic join features
Local schema support
Authentication of clients from joined directory, for example, from Active Directory
Granular plug-in systems to support custom extensions
Ability to compartmentalize information using dynamic views
Native support for web services at both integration and data access layers
Business Features and Benefits
Reduce implementation and administrative costs
Maximize and extend your existing infrastructure investments
Place all of your identity information under centralized management
Improve security and compliance
Unify multiple directories without synchronization
Provide LDAP interface to non-directory data
Combine data from multiple data-stores to create virtual entries
Provide application specific views of directory information
Expose Web Services as LDAP
Oracle Virtual Directory answers the challenge of addressing today's enterprise directory needs by delivering the following:
Oracle Virtual Directory enables directory services access that crosses political and corporate boundaries by acting as a directory gateway that processes client requests and dynamically re-routes them to one or more existing directories—regardless of format, be it LDAP, RDBMS, or others. Oracle Virtual Directory presents a virtual directory hierarchy, or tree, to its clients and then assigns hierarchy branches of that tree to designated LDAP or RDBMS servers. Oracle Virtual Directory handles the issues of inter-directory security, protocol, and data translation so that LDAP clients assume that all information comes from a single trusted LDAP directory, the Oracle Virtual Directory.
One of the least obvious—but most important—benefits of virtualization is data ownership. Organizations often create directories with specific purposes and objectives in mind. When another organization wants to access data owned by the first organization, questions arise about who ultimately owns the data and who controls it. Politics can occur when different parties want to use and share information. Everyone acknowledges the value in re-using existing data, but re-using data brings up many care and control issues. Many organizations become very concerned when copies of the data they feel they own goes to other organizations or outside parties. Questions such as the following are sure to arise:
Who is responsible for the data?
Who will ensure its accuracy?
Who will ensure its security and confidentiality?
If the information is copied, how does the owning organization assure itself that the information is being used and controlled by the other party?
Virtualization through proxy technology solves many of these political problems by keeping data where it belongs—with the data's owner. At any time, the owner can restrict or eliminate access to this data. Additionally, the owner is free to revise this information at will and can be assured that partners are always working with the latest relevant information. Most importantly, by keeping information with the owner, the use of that information can be continuously monitored and controlled by the owner.
Oracle Virtual Directory provides this type of data ownership by not copying information. Information accessed by Oracle Virtual Directory occurs in real time, assuring the consumer and provider that the information is current, accurate, and authorized.
Oracle Virtual Directory enhances security by providing new security domain contexts. When deploying new business applications across multiple business organizations, identity and security can be complicated by the existence of multiple directory security infrastructures. As Microsoft Active Directory administrators know, having multiple windows infrastructures (sometimes called forests) is great for administration and performance, but has a downside in that there is no automatic trust between forests and no inter-forest global catalogue.
Oracle Virtual Directory creates a new transitive security context with fine-grained access controls built to support all IETF standards for access control, while supporting the IETF models for implementation. Oracle Virtual Directory is also designed to properly integrate with security restrictions from the source directories it proxies, resulting in a multi-layer or multi-domain security concept that gives administrators the ultimate security control.
Oracle Virtual Directory supports a wide array of authentication models. In addition to SSL/TLS (including StartTLS) and certificate-based authentication, Oracle Virtual Directory can use server-to-server authentication with proxied servers (authenticating itself), or alternatively can pass user context through to source directories. By providing user-context at the Oracle Virtual Directory and source directory, both directories can provide end-user contextual security control.
Oracle Virtual Directory offers several data security features, for example:
SSL/TLS support: Oracle Virtual Directory offers SSL/TLS capabilities that provide for secure communication sessions with LDAP clients. This allows you greater security by allowing Oracle Virtual Directory to be the trusted transport mechanism.
Transaction Cleansing: Oracle Virtual Directory is based on a protocol conversion engine, which means that it deconstructs every query, recompiling and assessing validity before transmission to trusted proxied directory sources. This protects source LDAP servers from malformed or unauthorized queries. After cleaning the garbage requests, Oracle Virtual Directory can protect limited resources from exposure to huge loads from malicious attacks by providing the ability to set limits on items such as:
Maximum operations per connection
Maximum concurrent connections
Maximum total connections in a specified period for a particular subject
Maximum total connections in a specified period for a particular address
Access Control: Oracle Virtual Directory implements its own access controls and provides filtered access to internal proxied directory data.
A directory is only useful if the applications it serves can gain access to the data it needs in a form that has consistent formats or schema. But the typical enterprise environment contains a myriad of directory repositories with different schema, namespace, and data designs.
In addition to providing a secure bridge to existing directory information, Oracle Virtual Directory provides functionality like a meta-directory to translate and transform data in real time, enabling administrators to easily normalize differences in data found between different organizations and directory infrastructures. The resulting virtualized directory view contains all the directory information needed to run an application, without requiring you to build drastic changes or integration technology into the application.
Oracle Virtual Directory provides flexible deployment options that allow it to be embedded with commercial-off-the-shelf applications by developers and business application developers. Additionally, Oracle Virtual Directory can be deployed by a corporate IT department as a shared directory service distribution network.
Oracle Virtual Directory offers multiple high availability capabilities, including:
Fault Tolerance and Fail-Over: Oracle Virtual Directories provide fault tolerance in two forms:
they can be configured in fault tolerant configurations
they can manage flow to fault tolerant proxied sources
Multiple Oracle Virtual Directories can be quickly deployed simply by copying, or even sharing configuration files. When combined with round-robin DNS, redirector, or cluster technology, Oracle Virtual Directory provides a complete fault-tolerant solution.
For each proxied directory source, Oracle Virtual Directory can be configured to access multiple hosts (replicas) for any particular source. It intelligently fails over between hosts and spreads the load between them. Flexible configuration options allow administrators to control percentages of a load to be directed toward specific replica nodes and to indicate whether a particular host is a read-only replica or a read/write server (master). This avoids unnecessary referrals resulting from attempts to write to a read-only replica.
Load-Balancing: Oracle Virtual Directory was designed with powerful load balancing features that allow it to spread load and manage failures between its proxied LDAP directory sources.
Oracle Virtual Directory's virtual directory tree capability allows large sets of directory information to be broken up into multiple distinct directory servers. Oracle Virtual Directory recombines the separated data sets back into one virtual tree by combining the separate directory tree branches.
If you have multiple LDAP servers for a particular source, the Oracle Virtual Directory LDAP Adapter can load-balance and fail-over for these servers on its own. This load-balancing and fail-over happens transparently to the client and does not require any additional hardware or changes to the client connecting to Oracle Virtual Directory.
The Database adapter supports load-balancing and fail-over if the underlying JDBC driver provides this functionality. Additionally, Oracle Virtual Directory is certified for use with Oracle Real Application Clusters.
Oracle Virtual Directory Routing also provides load-balancing capabilities. Routing allows search filters to be included in addition to the search base to determine optimized search targets. In this load-balancing approach, Oracle Virtual Directory automatically routes queries to the appropriate virtualized directory sources enabling the ability to work with many millions of directory entries.
Note:
Oracle Virtual Directory's value is as a virtualization and proxy service, not as a directory store. If you need a highly available directory storage system, Oracle recommends using Oracle Internet Directory.Oracle Virtual Directory provides the following three main areas of extensibility, allowing customers and consultants to enhance the functionality of Oracle Virtual Directory to meet specific business or technical integration needs:
Oracle Virtual Directory Plug-ins: Oracle Virtual Directory provides a flexible plug-in framework modeled on Java Servlet Filters. You can use plug-ins to provide custom logic as part of a transaction or simply to connect to a custom data source. You can insert plug-ins globally or only for specific adapters. You can change the ordering of plug-ins and they can be isolated to particular types of transactions. Oracle Virtual Directory's management tools provide wizards for creating new plug-ins along with examples that you can use to get started quickly.
Custom Joiners: The Oracle Virtual Directory Join View Adapter is based on an extensible model known as Joiners. You can develop Custom Joiners to provide different joiner behaviors. Joiners provide functions such as mapping, joining, and pre- and post-handler event handling. You can write Custom Joiners to provide simple entry level joins, or extended Joiners to provide complex join logic, transaction handling, and rollback capability.
Web Gateway: Oracle Virtual Directory includes a customizable DSML/XSLT based gateway that provides basic web server support based on the Apache web server model that supports static HTML and XSLT rendered content. The gateway includes a directory-enabled interface allowing for queries and modification operations. Web server security enables custom delegated administration applications to be developed based on this interface.
Traditional directory integration solutions require complex LDAP provisioning and replication schemes and even synchronization to operate. These new directories then become yet another directory source that has to be maintained and managed.
As a light, real-time service, Oracle Virtual Directory improves efficiency by reusing existing directory infrastructure, rather than synchronizing and duplicating it. Oracle Virtual Directory extends the reach of existing enterprise directories and capitalizes on their value.
The following sections describe the Oracle Virtual Directory architecture and topology.
Oracle Virtual Directory Architecture
The Oracle Virtual Directory server is written in Java and internally it is organized into multiple layers, as shown in Figure 1-3. These layers are logical layers—Oracle Virtual Directory appears as a single complete service to the administrator and to clients.
The first layer is Oracle Virtual Directory's listener layer where socket-level protocol is spoken. Oracle Virtual Directory provides two types of listeners: LDAP and HTTP. Both listeners support SSL/TLS on top of their basic protocols. The LDAP layer also provides the ability to support LDAP-SASL to support digital certificate authentication.
The listener hands off requests to a worker thread which handles further processing to determine which action to take, such as a search or update. Operations appear the same internally to Oracle Virtual Directory whether it is an LDAP or DSML request. After the operation is determined, the first level of security checks are performed, including making sure the request is not in violation of any Denial of Service policies or inbound Oracle Virtual Directory-level access controls.
If the request satisfies the in-bound security requirements, the next step is to invoke any global level mappings and plug-ins. Mapping and plug-ins have the ability modify the operation such as changing the name or value of attributes. After invoking configured global-plug-ins, Oracle Virtual Directory determines which adapters can handle the request by processing the information provided in the operation.
The DN of the operation, that is, the search base in the search or the DN of the entry in an all other LDAP operations like a bind or add, is the primary information used. Oracle Virtual Directory examines the DN and determines which adapters could potentially support an operation for that DN. This is possible because each adapter configuration indicates what LDAP namespace it is responsible for. If multiple adapters can support the incoming DN namespace, for example, a search whose base is the root of the directory namespace, such as dc=oracle,dc=com, then Oracle Virtual Directory performs the operation on each of the selected adapters eligible for handling that request. The order of precedence is configurable based on priority, attributes, or supported LDAP search filters.
After Oracle Virtual Directory chooses an adapter, the next step is to invoke any inbound adapter level plug-ins, which are like global plug-ins except operate only on the specific adapter. After any plug-ins are invoked, then the adapter translates the Oracle Virtual Directory request into an operation that maps to its specific adapter level protocol. With the LDAP adapter, there is often very little translation, perhaps only to translate the incoming DN to a value that maps to its actual namespace. For example the incoming search might be for ou=staff,dc=oracle,dc=com and this is mapped to ou=hr,o=oraclecorp. However, with other adapters, such as JDBC using the Database Adapter, the requests are translated into SQL calls, or for custom adapters, the requests are changed into methods that match their proprietary protocols, such as Web Service calls.
After the operation is performed, the result proceeds in reverse order back to the client. In non-search operations, there is normally no further processing. In a search operation where data is returned, plug-ins (optionally) and access controls are processed on the data. The Oracle Virtual Directory access controls are designed to work with any existing access controls you may have in place with your data and act more as additional—not replacement—access controls.
At the conclusion of the operation, the listener level ensures the data is returned to the client in the proper format, such as LDAP or DSML entries.
Oracle Directory Services Manager
As of 11g Release 1 (11.1.1), Oracle Virtual Directory and Oracle Internet Directory have a unified graphical user interface (GUI) called Oracle Directory Services Manager. Oracle Directory Services Manager simplifies the administration and configuration of Oracle Virtual Directory and Oracle Internet Directory by allowing you to use web-based forms and templates.
As of this release, you can configure Oracle Directory Services Manager to use Single Sign-On (SSO). Once Oracle Directory Services Manager has been configured with SSO, Oracle Directory Services Manager allows a user who has been authenticated by the SSO server to connect to an SSO-enabled directory without logging in, provided that the user has an entry in the directory.
Refer to "Getting Started With Oracle Directory Services Manager" for more information.
Fusion Middleware Control
As of 11g Release 1 (11.1.1), you configure many Oracle Virtual Directory features from Oracle Enterprise Manager Fusion Middleware Control. This console enables you to configure and manage all Oracle products from one user interface.
Using the Oracle Enterprise Manager Fusion Middleware Control, you can monitor the Oracle Virtual Directory Server and related components and activities. The Oracle Enterprise Manager Fusion Middleware Control collects host names and ports that you specify during installation or configure at a later time. A Resource Discovery Service (RDS) identifies Server instances and associated components and sends information about these components to the Oracle Enterprise Manager Fusion Middleware Control. The Oracle Enterprise Manager Fusion Middleware Control depends on RDS to detect when nodes in the network are down, or if additional nodes are installed and configured from the Oracle Universal Installer.
Using the monitoring functions, you can gain insight into system activity and performance, for example, total logins, successful and unsuccessful logins, average login time, request latencies, LDAP connections, and so on.
You can monitor the following items:
Metrics: To monitor system health
General: A high-level rollup of load, performance, security, login, CPU utilization, and other data
Performance: Key metrics for the directory server and its host
Reports: Data on operation success and failure
Topology: Information on the Oracle HTTP Server instances, directory server instances, single sign-on servers, associated databases, and so on
Oracle Fusion Middleware is a collection of standards-based software products that spans a range of tools and services: From Java EE and developer tools, to integration services, business intelligence, and collaboration. Oracle Fusion Middleware offers complete support for development, deployment, and management.
Oracle Virtual Directory is a component of Oracle Fusion Middleware as a standalone Java 2 Standard Edition (J2SE) process. Oracle Virtual Directory utilizes several aspects of the Oracle Fusion Middleware framework, including integrating with the following:
Common Audit Framework
Common Logging Framework
Credential Store Framework
Oracle Enterprise Manager Fusion Middleware Control
The following is a list of Oracle Fusion Middleware concepts and terms related to Oracle Virtual Directory:
A WebLogic Server administration domain is a logically related group of Java components. A WebLogic Server domain includes a special WebLogic Server instance called the Administration Server, which is the central point from which you configure and manage all resources in the domain.
An Oracle WebLogic Server domain is a peer of an Oracle instance. Both contain specific configurations outside of their Oracle homes.
A WebLogic Server home contains installed files necessary to host a WebLogic Server. The WebLogic Server home directory is a peer of Oracle home directories and resides within the directory structure of the Middleware home.
An Oracle instance contains one or more system components, such as Oracle Virtual Directory. The system components in an Oracle instance must reside on the same computer. An Oracle instance directory contains updatable files, such as configuration files, log files, and temporary files.
An Oracle home contains installed files necessary to host a specific product. For example, the Oracle Virtual Directory home contains a directories that contain Oracle Virtual Directory binary and library files. An Oracle home resides within the directory structure of the Middleware home. Each Oracle home can be associated with multiple Oracle instances or Oracle WebLogic Server domains.
A Middleware home consists of the Oracle WebLogic Server home, and, optionally, one or more Oracle homes. A Middleware home can reside on a local file system or on a remote shared disk that is accessible through NFS.
See:
Oracle Fusion Middleware Administrator's Guide for complete information about Oracle Fusion Middleware.Oracle is the only vendor that provides a complete range of directory service solutions, including:
Scalable local-store based directory server with Oracle Internet Directory
Meta-directory with Directory Integration Platform
Directory virtualization with Oracle Virtual Directory
Use Oracle Internet Directory when you must store data in an LDAP server but do not have an existing directory server. Use Directory Integration Platform when you must synchronize databases or other directory information to Oracle Internet Directory. You can also use Directory Integration Platform to synchronize data between Oracle Internet Directory and certain Oracle applications, like Oracle eBusiness Suite. Use Oracle Virtual Directory to aggregate data from heterogeneous sources into a single directory service in real-time through direct data access.
You can use the Oracle Directory Services products independently of each other or with each other. For example, you can use Oracle Virtual Directory with Oracle Internet Directory to provide a DSML interface to Oracle Internet Directory data. You can use Oracle Internet Directory to provide scalable storage for information to manage using Oracle Virtual Directory and that does not have an existing directory to leverage. Also, Directory Integration Platform with Oracle Internet Directory can use Oracle Virtual Directory to provide additional fault-tolerance support for existing virtualized data-stores. For example, if for some reason your primary enterprise directory becomes unavailable, Oracle Virtual Directory can use the Oracle Internet Directory store.
This topic describes many of the obstacles traditional directory servers and enterprise directories face today when deployed for identity management configurations and also explains how Oracle Virtual Directory can solve them.
Overview: Traditional Directory Server Shortcomings
Today's directory servers are designed as specialized databases and by themselves, they do not provide enterprises with the tools needed to connect all possible applications into a single enterprise directory. With very few exceptions, no company has a single enterprise directory.
According to analysts, the majority of companies have several (five or more) directories used company-wide. If their intent is to provide data to an application that is used by multiple business partners, then the number of directories increases by at least the number of business partners using the application. Oracle believes that most enterprises need multiple tiers of directory services both internally and externally. Oracle Virtual Directory is one of the best ways to provide this requirement without duplicating data and without incurring large replicated infrastructure costs.
Typical directory and database technology fails to resolve issues that arise when corporations are made up of independent business units, divisions and partners. Today's directory server technology forces companies to build a single managed data infrastructure that requires huge political discussions on the following topics:
What data should the directory infrastructure contain?
Who will manage it?
Who will fund it?
Issues such as who should pay for directories and who should manage them become critical factors that affect the success of deploying what should be relatively simple database technology. As shown in Figure 1-4, there can be numerous directory sources in different formats and geographies, but also, owned by different parties. Additionally, other directories such as relational databases and email systems can and are added to these traditional enterprise directories.
The issues surrounding distribution of data are further complicated by the addition of LDAP-enabled applications such as Lotus Domino and Microsoft Exchange that have directory information but do not readily integrate into existing enterprise directories due to differing requirements in schema.
Developers have traditionally succeeded at creating databases for specific purposes, because decision-making is driven by individual business managers sponsoring business-driven applications. Now, the new trends of business-to-business web services and inter-business applications means that the data sources within external partners must be considered in the creation of a directory services and security infrastructure strategy.
A directory service integration layer is needed to handle practical issues such as:
Distributed Security: availability and verification
Routing: how to get to different data
Integration: how to handle differing formats
Data-level Federation: merging trusted directories
Oracle Virtual Directory is Oracle's answer to this challenge.
The following sections describe in detail common obstacles traditional directory servers face and how you can use Oracle Virtual Directory to resolve them.
Clogged Replication
Directory services are frequently deployed over time with a single primary or "master" node and multiple replication nodes. Over time, you may developed multiple hierarchies of directories to facilitate regionalized replication, which in turn support regional directory farms.
As time passed though, replication may slow down to the point where the directory replica servers are outdated. The main cause for slow replication is the maintenance of searching indexes. Often, reviewing the indexes and minimizing indexes can extend the life of an existing infrastructure.
However, at some point, directory indexing demands will outweigh any individual server's ability to keep up with and replicate changes for it. An alternative is to consider breaking the replicas into special purpose or class-of-service nodes. For example, one pair of replicas might be dedicated to handling user search and policy server requests. Another pair might be dedicated to performing white page or email searching requests. Other servers might be tuned to the needs of specific applications.
In Figure 1-5, the indexing strategy has been adjusted to create Class-of-Service replicas enabling replication to scale. Each class-of-service defines a set of directory replicas designed for specific application clients.
In this case, Oracle Virtual Directory automatically knows where the master server is and routes modified traffic directly to it—avoiding a needless directory referral operation. The next challenge is how to route applications to the correct replicas for the correct searches based on class-of-service.
One easy way is to assign directory replicas directly to applications. However, this strategy might not work since applications may use a greater variety of searches than can be configured on any particular directory replica. Instead, you can use the Oracle Virtual Directory virtual directory to automatically route each search request by using its routing include and exclude filters. These filters allow the administrator to decide which operations each proxied node may and may not perform.
Figure 1-6 shows a typical request where that application is looking to locate a user-distinguished name by searching on UID. Oracle Virtual Directory recognizes the search filter and routes the request to the appropriate directory replicas. Notice that Oracle Virtual Directory can select from multiple nodes and provide load balancing between the nodes, allowing it to spread load across multiple nodes and ensure fault tolerance by not having to rely on any single node.
For different kinds of searching operations, for example, white pages, or classes-of-service, Oracle Virtual Directory can route to alternate directory replicas.
If none of the filters are matched, a default server can be designated. This server might be set up as a low-performance server and lag in replication since it may have more general purpose indexing.
In all of these cases, you see only a single Oracle Virtual Directory. In reality, multiple, identically configured Oracle Virtual Directories can be deployed according to the fault tolerance and loading requirements of the servers. Because Oracle Virtual Directory holds no data, the architecture is 100 percent parallel, allowing for unlimited growth. For example, it is possible to deploy a server pair per application client if needed. Since each server holds no data, and therefore requires no backups, and simply acts as a router, each server adds minimal management costs to the overall infrastructure.
Transaction Failover
Many enterprises have deployed fault-tolerant infrastructures, using devices such as F5 BigIP to route LDAP traffic to available directory server nodes. Because LDAP provides atomic single unit transactions, it has often been assumed that applications would be able to deal with transaction failures. If an LDAP operation fails, it has always been assumed that the application knows to reconnect and try again. For service architects, this has presented many obstacles as some applications replay invalid transactions on multiple directory servers or the application fails and does not realize it just has to try again.
Oracle Virtual Directory addresses this problem through an intelligent connection pooling mechanism designed to spread application load across multiple directory servers. Since the connection pooling spreads individual transactions across multiple servers, Oracle Virtual Directory realizes when a transaction times out or fails on a particular node and allows the operation to be transferred to another node. Oracle Virtual Directory determines whether this is a data failure, in which case it is returned to the client, or whether it is a service failure. If there is a service failure, Oracle Virtual Directory attempts to repeat the transaction on each available server until all servers have been exhausted. Only then is a failure returned to the client.
For advanced protection, global failover can be configured by adding non-local directory nodes to Oracle Virtual Directory's server list. When configured this way, a load percentage of 0 is assigned to these non-local nodes in the LDAP Adapter's LDAP Servers configuration. This forces Oracle Virtual Directory to use these nodes only when no other local node is available, providing the ability to route traffic locally while still being able to send it to other sites in times of need.
Connection Domination
In many large-scale directory environments, there may be several applications that dominate and do not share connections. At application bootstrap time, an application is assigned a directory server, for example, by F5 BigIP, and it establishes a permanent connection with that server, causing the following problems:
Fault-tolerance and load-balancing is effectively bypassed. Since most traditional approaches use connection-based load balancing and failover, a connection-hungry application cannot be easily moved from an overloaded directory server.
An overwhelming load is created. Since the application tends to use only one directory, its load requirements may exceed the capabilities of the node to which it is assigned. By never relinquishing a connection, there is no opportunity for the management systems to re-adjust the load.
Virtual directory technology helps by providing a connection pooling mechanism that distributes load on a transaction-by-transaction basis. Oracle Virtual Directory maintains a minimum number of connections with each of its proxied directories and adds connections as load requires. Oracle Virtual Directory provides automatic switching of the single client connection and spreads its operations over multiple directory servers, making the directory service more stable because no single directory server node is overloaded. While Oracle Virtual Directory maintains a single connected session between it and the connection dominate client, Oracle Virtual Directory itself is a "good citizen" with the infrastructure and provides load distribution and periodic connection refreshes.
Application Connection Overload
The opposite scenario to the connection domination problem occurs when too many applications make connections and overload the directory server with too many TCP/IP connections and LDAP bind requests. When this happens many directory servers, including LDAP and X.500 versions, can become unstable as they run out of system resources or simply run out of processing threads. Many benchmarks show that most directory servers have a peak performance level at around seven to ten simultaneous connection threads. This information indicates that while the server may be capable of answering many more calls, peak throughput is diminished as the server starts to spend its time establishing connections rather than servicing requests, as shown in Figure 1-7.
Oracle Virtual Directory's connection pooling mechanism resolves this issue. As with the connection dominating client, Oracle Virtual Directory uses its pool to share connection between many clients, and uses rebinding to switch between user contexts where necessary (depending on the mode of the Oracle Virtual Directory pass credentials setting). Oracle Virtual Directory takes many client connections and their requests and multiplexes transactions over a reduced number of connections to the proxied servers. Since existing connections are reused, the amount of consumed resources on the proxied server is greatly reduced, allowing it to focus on LDAP transaction processing.
Data Overload
In some cases, optimizing directory replication schemes is not sufficient to create the scale needed for extremely large directories, as described in the Clogged Replication section. In these cases, the ability to create a directory in the tens or hundreds of millions of entries depends on the ability to divide data into smaller pieces and create a virtual view where all the separate pieces appear in a single directory view—a divide and conquer approach.
Oracle Virtual Directory provides several means to accomplish this virtualization. The simplest way is to exploit directory hierarchy. If the data can be broken down into a hierarchical structure, then multiple directory groupings can be created where each grouping owns one or more namespaces. This allows Oracle Virtual Directory to route traffic by simply looking at the distinguished name and deciding which directory grouping to use.
For example, if a hypothetical telephone company had customers grouped by area code, then Oracle Virtual Directory could route traffic by looking at the organization unit containing the area code as shown in Figure 1-8. For all modify and bind operations, traffic is routed solely on distinguished name. For searching operations, as described in the Clogged Replication section, routing include and exclude filters would be used to direct traffic based on search filters in the event the search base must be o=BigCo and cannot be namespace-specific.
If a flat hierarchy is needed, for example, where all entries appear to be under the same parent, you can choose to either parse the relative distinguished name (RDN), which is the left-most distinguished name or DN component, or to use prefetch operations. If the RDN component can be parsed, then routing could be established with a plug-in that parses the RDN to make routing decisions, as shown in Figure 1-9.
For example, if a DN were of the form: number=6046331751,ou=Account,o=BigCo, then the routing filter could select based on the first 3 digits (in this case 604) to select a particular directory grouping.
If the DN were of the form uid=jdoe,ou=Accounts,o=BigCo, the routing could use a hash table to decide that accounts beginning "a-l" are in one server, "m-r" in another, and "s-z" in a final grouping.
In this case, you can use a routing plug-in mechanism to supplement standard routing features. The intent of the plug-in is to allow you to describe the criteria under which the data should be separated. The selected criteria must ideally be available within every transaction, either in the DN or the filters and base.
The other alternative is to use prefetch. If the data has been divided such that there is no predictable way, at least to Oracle Virtual Directory, to determine where it occurs, Oracle Virtual Directory must then search directories based on customer-specific criteria to locate the correct repository. For example, on an LDAP modify operation a search must occur first to locate the modify repository. There must be a similar requirement for bind, delete and rename operations. On an LDAP add operation, there must be sufficient information in the add request to determine which repository receives the add request. In some situations, performance overhead could be moderated with a special master directory that the server uses simply to locate entries in the infrastructure.
Conclusion
You can use Oracle Virtual Directory in fault-tolerant configurations at various points in a global directory services deployment as shown in Figure 1-10. As a load balancer, Oracle Virtual Directory can be placed between site IP Routers, for example, WebSphere Edge Server and F5 BigIP, and site replica servers. Oracle Virtual Directory provides transaction level load balancing and fault tolerance between servers in the location. In addition to load balancing, Oracle Virtual Directory can offer multiple infrastructure level views of the data, including information from relational database sources through JDBC.
For those applications requiring a special directory view or the ability to have global transaction failover, Oracle Virtual Directory can be deployed as a middleware component directly on application servers. This strategy makes the application capable of switching between different locations if a site failure occurs. Normally, in this configuration, Oracle Virtual Directory would provide load balancing only at the local level while switching to other location nodes only when local services have failed.
Oracle Virtual Directory's flexibility enables directory architects to develop complex, robust directory service infrastructures. As an integration tool, Oracle Virtual Directory assists developers in using enterprise infrastructure as leverage in the easiest possible way. As an information router, Oracle Virtual Directory is quick to deploy, easy to manage and has an extremely low cost of operation.
Oracle Virtual Directory provides the functionality and performance required to manage large-scale deployments more effectively. As organizations look to solve enterprise-level data issues, Oracle Virtual Directory offers multiple solutions to some of their most challenging concerns.
You can deploy Oracle Virtual Directory in several different environments to resolve obstacles faced by traditional directory solutions. Figure 1-11 shows example deployments for Oracle Virtual Directory in two different environments, Intranet and Extranet.
Intranet Identity Example
The following steps explain the sequence of Oracle Virtual Directory's role in the intranet example displayed in Figure 1-11:
At the lower left-hand corner of the figure, an internal end-user accesses an intranet based web application. The application may or may not include a policy server as part of its own infrastructure.
The application or policy service requests the user's identification and password when the end-user accesses the application.
The application or policy service accesses Oracle Virtual Directory using LDAPv3 to validate the credentials using an LDAP bind request.
Oracle Virtual Directory in turn routes this request to the local directory server store and validates the credentials. On validation, Oracle Virtual Directory returns the verified results to the application.
In a further request, the application requests the user's directory entry from Oracle Virtual Directory so that their application profile and rights can be retrieved. Oracle Virtual Directory performs a transparent join, combining attributes from both the local directory server and information from a RDBMS. Once collected, Oracle Virtual Directory merges the result into a single virtual entry and returns it to the intranet application.
Extranet Identity Example
The following steps explain the sequence of Oracle Virtual Directory's role in the extranet example displayed in Figure 1-11:
In the upper right-hand corner, an external organization or business partner end-user accesses an extranet-based web application.
The application contacts Oracle Virtual Directory using LDAPv3 to verify the user's credentials using an LDAP bind.
Oracle Virtual Directory recognizes the credential maps to an external directory. Oracle Virtual Directory connects to the external Oracle Virtual Directory as the business partner using an SSL encrypted link and uses its own credentials to validate the inter-business unit query.
Once the business partner's Oracle Virtual Directory has validated the Oracle Virtual Directory, it recognizes the request and passes it on to the internal LDAPv3 directory.
Oracle Virtual Directory applies the appropriate inter-business access control and returns the filtered results from the directory back to Oracle Virtual Directory, which is then able to validate the password of the business partner user and return success or failure to the application.
Finally, as in the intranet application example, the application might then query Oracle Virtual Directory for additional attributes about the user. Oracle Virtual Directory performs a join linking client-supplied information from the business partner directory with locally stored information in the corporate database.
Example Summary
The examples in Figure 1-11 demonstrate capabilities across a complex scenario. You see Oracle Virtual Directory acting as an information router and joiner, brokering information from multiple secure sources to meet the needs of an application or security infrastructure. Not only can Oracle Virtual Directory bring together information from within a single intranet, it can also leverage information from business partners. This is particularly important because it allows business partners to use the extranet application without having to be provisioned or managed in the host business's directory. Business partner users are authenticated by their own local directory in real time.
Oracle Virtual Directory can also play an important role as a LDAP Proxy server. Oracle Virtual Directory may optionally be used by business partners to act as a directory firewall. Oracle Virtual Directory properly authenticates and authorizes external access to internal directory information. In the bottom right of the diagram you also see how Oracle Virtual Directory's own routing capabilities allow it to route to multiple internal directories or Windows Active Directory forests keeping this information away from the client. As a firewall, Oracle Virtual Directory controls and limits access to information as seen by authorized external parties. As a virtual-directory component, Oracle Virtual Directory simplifies and restructures data for publication of data to be used by business partners.
Oracle Virtual Directory enables you to connect to any source directory tree and map it to a new virtual tree. For example, an entry in a source directory has the following distinguished name (DN):
cn=Jim Smith,ou=People,o=Division B, c=UK
This source directory entry can be mapped to:
cn=Jim Smith,ou=People,ou=Division B, ou=People,o=AppView
In this example, Oracle Virtual Directory maps all entries below o=Division B, c=UK to ou=Division B, ou=People, o=AppView. Oracle Virtual Directory is performing an on-the-fly translation making Division B users appear to be part of the application-specific directory.
Figure 1-12 shows a local directory branch specific to the application. The root of the tree is o=AppView. Under this branch, local information such as application access control and roles can be stored, for example, cn=User Group,ou=Groups,o=AppView.
The application may have an architectural limitation that it only searches for users under a common people branch. To meet the application requirement, the design objective can be changed to have the new directory design map all directory sources underneath the ou=People branch. Figure 1-13 shows how this can also be represented:
In Figure 1-13, Oracle Virtual Directory is configured with four adapters:
Adapter 0 forms the root of the directory tree and maps to o=AppView. This adapter holds the virtual root of the tree and local entries such as access control groups.
Adapters 1-3 map each directory source to positions beneath the ou=People branch of the new application tree.
|
 Copyright © 2011, Oracle and/or its affiliates. All rights reserved. Legal Notices |
|
