424 Part III: Identity Management Joining Information in OVD A join view is conceptually similar to a database view, where information from other adapters is joined together using some condition, or “joiner.” A join view typically has a “primary” source for the user data that is then unified with a “joined” source to create the extended user profile. Consider this example: An LDAP profile for a user contains the standard LDAP attributes (name, location, contact, and so on). However, you are required to augment the basic user profile with a new attribute called clearanceCode for applications that need that piece of user data that lives in an external relational database. This is a great use case for using an OVD join view adapter; you can augment the basic LDAP profile with the additional attribute whose value is stored in the database. Figure 10-15 illustrates use of the join view concept in this scenario. In OVD, the join view is implemented using a join view adapter that essentially integrates a view on top of the existing adapter integrations to the backend sources of data. In our example, the join view is created over the LDAP adapter integration to Active Directory and the database adapter integration to the Oracle Database. The LDAP adapter will be the “primary” source for the join view since the majority of the data lives in that repository. The additional attributes from the database table will be used to augment the user profile information coming from Active Directory. Figure 10-16 illustrates the relationship between the join view adapter and the other adapters to create that unified view of a user. It’s worth restating that the join view technology is analogous to database views, because the data is maintained in its original location and the view merely provides a single entry point that optionally translates the original data and then merges it together. To achieve a proper unified view, you need to carefully consider certain aspects of the design. Design Considerations for a Join View Before we demonstrate the actual steps for creating the join view adapter, we need to decide on certain key characteristics of the joined view—data sources, join conditions, and data presentation. The following sections discuss some options at hand along those three areas of design. FIGURE 10-15 Using a join view to unify a user profile from multiple sources of data Chapter 10: Oracle Directory Services 425 Primary Adapter Our first design decision with regard to a join view adapter is the selection of a primary adapter underneath the join view adapter. The primary adapter is typically the source where the majority of the user profile resides. This is typically the enterprise LDAP server (Active Directory in our example). Binding Adapter The second design decision is the authoritative source of the authentication attribute (that is, user’s password). Any LDAPBIND operation request through the virtual LDAP server will route to this adapter to perform user authentications. Typically, this adapter is the same as the Primary adapter. In our example, we will set Active Directory as the binding adapter. Joiners A joiner is similar to a database foreign key that connects records between two relational tables. In this case, a joiner connects LDAP entries from two existing OVD adapters to look and feel like a single LDAP entry in OVD. Each of the three types of joiners is specialized for a specific scenario: Simple joiner The simplest form of joining uses an attribute value equality test to join two LDAP entries. A simple joiner supports a rule such as uid=uid, where the join adapter can unify all the LDAP entries that share the same value uid attribute. This is one of the most common joiners in use for OVD implementations. A simple joiner will take an entry from the primary adapter and join it with the first matching entry in the joined adapter. If more than one entry exists with the matching value, the subsequent entries will be ignored. ■ FIGURE 10-16 Join views used to rationalize the other OVD adapter integrations 426 Part III: Identity Management One-to-many joiner A one-to-many joiner is identical to a simple joiner, except it can join one entry from the primary adapter with many entries from the joined adapter. This type of adapter is useful when you’re trying to join entries with multi-valued attributes that are populated by multiple records from the joined adapter source. Consider this example, in which we want to create a new LDAP group called Data Architecture based on a database table that already maintains member information: SQL> select user_id, user_group from user_group_memberships; USER_ID USER_GROUP BJOHNSON DATA_ARCHITECTURE BWISE DATA_ARCHITECTURE TMUTH DATA_ARCHITECTURE BJOHNSON DATA_ANALYST DKNOX NETWORK_SECURITY RWARK ORACLE_DBA 6 rows selected. Using the one-to-many joiner, you can unify all the group memberships to be presented through the multi-valued uniqueMember attribute of the virtual group object in the OVD tree. An LDAPSEARCH request on that group object would look like the following from the OVD client’s perspective: $ ldapsearch -h hostname -p 389 -b dc=oracle,dc=com "(cn=Data Architecture)" uniqueMember dn: uid=Data Architecture,ou=Groups,dc=oracle,dc=com uniqueMember: uid=bjohnson, ou=Users,dc=oracle,dc=com uniqueMember: uid=bwise, ou=Users,dc=oracle,dc=com uniqueMember: uid=tmuth, ou=Users,dc=oracle,dc=com Shadow joiner This type of joiner can augment the standard set of attributes of an LDAP schema with an application-specific set of attributes. If an application wants to maintain a set of custom attributes as part of LDAP entries, a shadow joiner can be used to join the primary user profile with the “shadow” repository where these extended custom attributes are stored. Using this approach, the application writes the attribute to OVD via the LDAP interface; OVD then “quietly” writes this back to the shadow repository without touching the profile in the primary LDAP server. Shadow joiners eliminate the need to extend existing LDAP schema to support custom attributes that are application- centric. This joiner is useful when you’re faced with legacy applications that rely on custom attributes, and it provides a way to centralize their directory needs without significant code rewrites. Adapter Visibility When you set up an adapter in OVD, by default, all the data is public and available to all external LDAP clients. In most circumstances, the purpose of the virtual directory is to rationalize all the data from all the backend sources and present a single view of the ■ ■ Chapter 10: Oracle Directory Services 427 directory tree. This means controlling the visibility of each adapter we have setup in OVD and enabling visibility only on the adapter that presents the truly rationalized view. In our example, we configured integrations to an LDAP server and a relational Oracle table and rationalized those two integrations using the join view adapter. As a result, it makes sense to let the LDAP clients see only the data presented through the Join view. To enable this, we need to configure the Visibility flag of all the adapters we have configured. Three settings are used for Visibility: Yes Adds the adapter data to the directory tree presented to the public No Completely hides the information from all entities Internal Hides the information from public access but makes it available for internal plug-ins and adapters In our example, we want the following values for each adapter: Join view adapter: Visibility = Yes LDAP adapter: Visibility = Internal Oracle Database adapter: Visibility = Internal Figure 10-17 illustrates how to set the visibility of an adapter (the full-time employees from Active Directory integration in this scenario). ■ ■ ■ ■ ■ ■ FIGURE 10-17 Setting OVD adapter visibility 428 Part III: Identity Management Creating the Join View Adapter After thinking through the key design considerations for making a join view of all identity data and therefore creating a truly virtual unified LDAP directory profile, you can take the steps to create the join view adapter itself and implement all those design decisions. 1. Create a new adapter in OVD of type “Join View Adapter” with the following attributes (as shown in Figure 10-18): Adapter Suffix/Namespace: cn=Employees,dc=oracle,dc=com Primary Adapter: Full-time Employees Binding Adapter: Full-time Employees ■ ■ ■ FIGURE 10-18 Creating join view adapter Chapter 10: Oracle Directory Services 429 2. Set up a join rule to map users from the LDAP repository with records in the database table. Inside the configuration panel of the join view, create a new join rule with the following attributes, as shown in Figure 10-19: Joined Adapter: User Clearance DB Type/Class: com.octetstring.vde.join.SimpleJoiner Condition: uid=uid (this condition connects LDAP entries and Database records that share the same uid value) 3. Now you can test your newly created join view of users and their information in OVD. Figure 10-20 demonstrates the results. ■ ■ ■ FIGURE 10-19 Creating a Join Rule FIGURE 10-20 Testing the join view 430 Part III: Identity Management You can now see that the two additional attributes that we “joined” from the database records (Clearance Level and Clearance Code) are now represented through the LDAP interface as part of the user’s overall profile that includes the Active Directory details. The key point to remember is that throughout this entire process of integrating data from backend source to the OVD server, no data was physically moved or synchronized. The data still lives and is managed using the technologies and processes that existed before OVD was introduced into the picture. However, now all applications and clients have a common interface for querying and viewing that information. Summary The key characteristic difference between the directory and a generic user database (such as an HR database) is that an enterprise directory exists for the purpose of providing fast access to user data, mainly for security-related tasks inside applications. This focused scope of the directory’s charter should drive all directory design and implementation decisions. Oracle products such as Oracle Internet Directory (OID) and Oracle Virtual Directory (OVD) provide focused capabilities for building that fast and efficient user repository. However, the architects and developers of the directory still need to spend sufficient time and research on answering the key decisions about the data that goes into the directory: scope, source, structure, presentation, and semantics. Those decisions are highly subjective to the organization and can rarely be automated by tools and technologies. Once those decisions have been made, technologies such as OID and OVD, if applied correctly, can make a significant difference in your getting to the end state of having a simple, flexible, and rationalized user directory that any application can leverage for identity management purposes. PART IV Applied Security for Oracle APEX and Oracle Business Intelligence This page intentionally left blank CHAPTER 11 Web-centric Security in APEX 433 . directory design and implementation decisions. Oracle products such as Oracle Internet Directory (OID) and Oracle Virtual Directory (OVD) provide focused capabilities for building that fast and efficient. and is managed using the technologies and processes that existed before OVD was introduced into the picture. However, now all applications and clients have a common interface for querying and. view is created over the LDAP adapter integration to Active Directory and the database adapter integration to the Oracle Database. The LDAP adapter will be the “primary” source for the join