Example of a Virtual Directory Using the Join View Adapter

2-24 Oracle Fusion Middleware Administrators Guide for Oracle Virtual Directory ■ Adapter 4 is a Join View Adapter. In this case, Adapter 2 for the Enterprise Directory, is used as the primary adapter and therefore all entries displayed by Adapter 4 exactly mirror the entries in Adapter 2. With nothing else defined, the Join View Adapter is a carbon copy of Adapter 2. After configuring the adapters you must define join relationships. In this situation you define two join relationships: one to Active Directory and one to the corporate RDBMS. For the Active Directory join, you define a Simple Join in Adapter 4 to Adapter 2—note that you are really joining with the primary adapter, Adapter 1. To complete the join, specify unique criteria that joins entries in Active Directory to the primary adapter. As shown in Figure 2–7 , use uid=userprincipalname where uid is in Adapter 1 and userprincipalname is in Adapter 2 Active Directory. For the second join, you join with Adapter 3 using a Simple Join and use uid=userid to achieve a unique match. Figure 2–7 Specifying Unique Criteria Between Joins Lastly, because you want to use Adapter 1 for authentication rather than the primary adapter Adapter 2, you set the bindadapter setting to 1, causing the Join View Adapter to test authentication against the joined adapter rather than the primary adapter. Note: If you wanted users to match multiple RDBMS records for example, a privilege table, you could specify a OneToMany Join such as approle=priv. In this case approle would be an attribute in the enterprise directory. The approle attribute matches up with a series of privileges in the RDBMS. By performing the join in this example, you would translate a simple role into a series of privileges. AppView Adapter 0 Groups Application People People userPrincipleName = uid Joined Users Adapter 4 RDBMS Data Adapter 3 = userid Enterprise Directory Adapter 2 Active Directory Adapter 1 Understanding Oracle Virtual Directory Adapters 2-25 After Adapter 4 is configured, you can hide Adapters 1, 2, and 3 from end users by setting Routing Visibility on each of these adapters to Internal. This results in a directory that appears to have a single ou=People,o=AppView branch. As you browse the directory below ou=People, you are querying Adapter 4, the Join View Adapter. When the Join View Adapter receives queries, it automatically transforms and passes them on to the other three hidden adapters. Ultimately the application perceives that there is only a single entry for each person.

2.8 Understanding Adapter Namespaces

Figure 2–8 shows a source directory tree structure where there are four separate directories. The goal is to combine all four separate directories into one new directory tree design. The most basic directory tree design you can implement with Oracle Virtual Directory is with no translation so the source directory structure with four separate directory trees is valid within Oracle Virtual Directory and it is operating as a pure directory proxy using no translation features. Figure 2–8 Example Source Directory Tree Structure with Four Separate Directories Figure 2–9 shows that two external companies were added as descendants to o=YourCompany, c=US. In this example, Adapter 1 and Adapter 2 occupy subtree entry positions relative to Adapter 0. At the same time, Adapter 3 is left occupying a separate namespace, which could represent a third-party company that provides administrative network services and may not participate in the business application of the other three organizations. In this is the case, it may be best to keep the ISP directory entries separated. Partner London San Francisco User Airius.com User User Baltimore Adapter 0 People Your Company User User Contractors Adapter 2 Adapter 1 UK US Service Provider Administrators User2 Adapter 3 UK2 2-26 Oracle Fusion Middleware Administrators Guide for Oracle Virtual Directory Figure 2–9 Example Source Directory Tree Structure with Two Additions Figure 2–10 shows the directory structure after it was redesigned so that all partner users are under the ou=People branch. This requirement may be due to a limitation in an application for example, it only authenticates users from a single base of ou=People, o=YourCompany, c=US. Notice that YourCompanys people entries are directly under ou=People while the partner directories are contained within organization units under ou=People. Keeping the organization unit allows for easier creation of access control groups and roles specific to users of those partners and avoids namespace conflicts. Notice also that only one adapter may occupy any particular node in the tree. Adapter 0 People Your Company User4 Contractor User5 Administrators Service Provider User Adapter 3 London Partner User3 Adapter 1 Baltimore San Francisco User User2 Adapter 2 Airius.com US UK