Applied Oracle Security: Developing Secure Database and Middleware Environments- P45 ppsx

414 Part III: Identity Management Initializing the Virtual LDAP Tree Using a Local Store Adapter Before any physical information is presented through a virtual directory, you need to define and design the directory tree and namespace that organizes all the information across the enterprise. Traditionally, this part of the project can often be a paralyzing step since it requires that people agree on a common namespace. However, OVD supports the notion of a virtual namespace. You are no longer permanently committed to namespaces, and, in fact, you can now host multiple namespaces in the same virtual directory to support two models for organizing the same identity information. However, it is recommended to keep it simple and unified under a common namespace. In this example, we will use the namespace dc=oracle,dc=com as our common unified namespace and integrate data from multiple repositories under a common directory information tree. The easiest way to create the root of the namespace is to use a Local Store Adapter (LSA) in OVD. An LSA uses a file-based repository to hold a relatively small quantity of information. It is recommended to limit the use of the LSA for only the root node of the directory tree. It is not a good idea to have the LSA store actual users since it is not meant to scale for high volume identity data. Once you define the root node of the tree, you can start integrating the identity repositories that contain the full scale of identity data about all users in the enterprise. The following example uses a scenario in which different types of identity data is split across Active Directory and OID, you can use the LSA to create a single logical directory tree that can reconcile the two physical directories by integrating that data underneath the namespace defined by the LSA. Figure 10-5 illustrates this design pattern. FIGURE 10-4 Configuring the basic details of the OVD Server Chapter 10: Oracle Directory Services 415 Setting up an LSA involves the following steps in the OVD Manager: 1. Right-click the Adapters node under the OVD server you created previously and select a New Local Store Adapter. 2. As shown in Figure 10-6 on the next page, fill in the adapter name, the adapter suffix, and the remaining details as you desire (the defaults values are recommended for testing this integration). Keep in mind that OVD does not immediately “push” this configuration into the server to take effect. You need to explicitly make that request to upload the configuration change to take effect. The easiest way is to right-click the OVD server and select Save All to Server. To test that your OVD is running on a the configured LDAP port and is exposing a directory tree with the namespace dc=oracle,dc=com, you can right-click the OVD Server and select Open Server Browser. This should refresh the Data Browser panel at the bottom with a Client View node. Expanding the Client View node should show if the directory root was created properly (in our case dc=oracle,dc=com), as shown in Figure 10-7 at the bottom of the next page. However, clicking the node should result in an error: “object does not exist.” That is expected since you have simply defined the tree’s root without any substantive data. The next few sections will show you how to add that substantive data (from the physical sources) to your virtual directory tree. Integrating OVD with an Active Directory LDAP Server Now that the root of the tree has been successfully created in the virtual directory, you can start populating the tree with information about users from actual physical repositories, such as the enterprise Active Directory server. The first step of a physical LDAP server integration is to create FIGURE 10-5 Directory tree design using OVD 416 Part III: Identity Management FIGURE 10-6 Configuring the basic attributes of an LSA FIGURE 10-7 Testing whether the new directory tree was created by the LSA a new LDAP adapter in the same way you created one for the LSA. However, the configuration information is related to the external LDAP server. Figure 10-8 shows a sample LDAP adapter configuration for Active Directory. In this scenario, a directory of full-time employees is being integrated. Chapter 10: Oracle Directory Services 417 In Figure 10-8, notice the following details: The Active Directory namespace: CN=Users,DC=aos,DC=oracle,DC=com The OVD namespace mapped to the AD namespace: CN=Employees,DC=oracle,DC=com You can see how the existing AD namespace was easily transformed to look like a global enterprise namespace using a much more functional view of my users rather than a technical system view. At this point, you can go back to the Data Browser panel in the OVD Manager console and test out this integration by right-clicking the Client View node and selecting Refresh Current Node. ■ ■ FIGURE 10-8 Creating an LDAP adapter to integrate with Active Directory 418 Part III: Identity Management Notice that the Client View node in Figure 10-9 shows the LDAP integration directly at the node DC=Employees,dc=oracle,dc=com, and also under the desired root node (created by the LSA) so you can choose where to start your queries. Active Directory is one of the outlier directories that does not use the inetorgperson object class and instead uses a proprietary naming standard for user attributes. For example, Active Directory uses employeeID instead of the standard inetorgperson employeeNumber. The inetorgperson object class has become a widely-used user data model standard in many web and client-server applications, so it makes sense to rationalize and map proprietary naming conventions to the standardized inetorgperson using OVD’s mapping capabilities. OVD has a prebuilt plug-in called InetAD that provides this normalization between Active Directory and inetorgperson as a standard feature. You can implement this by following these steps: 1. Open the LDAP adapter configuration by double-clicking your Active Directory LDAP Adapter in the OVD console. 2. Select the Plug-in tab and select New Plug-in. 3. In the Plug-In Definition window shown in Figure 10-10, click Select From Server for the class. 4. Select InetAD from the list and then click through Next and Finish to complete adding this plug-in to your AD configuration. FIGURE 10-9 The Data Browser is an effective and easy tool to test LDAP integration Chapter 10: Oracle Directory Services 419 The plug-in is now ready to be fired any time a query is run against the data originating from the Active Directory server. This is one example of how OVD can dynamically transform data to meet certain requirements of the client or the application using this data. You can now test this plug-in by going back to the client view and looking the details of one of your Active Directory users. You should now see the object class inetorgperson as part of every AD user. You just witnessed an example of how OVD integrates existing physical LDAP servers. In the process, data was normalized and changed to a common representation. Next, we will discuss this same idea of integrating more backend sources; however, you will see how you can apply OVD to integrate information from non-LDAP sources, such as relational databases. Integrating OVD with an Oracle Database In this section, we explore the possibilities of leveraging more than just LDAP information for making access control decisions. While LDAP servers are the designated place to store and access identity information, it is often insufficient for making very critical access decisions. Often, you need to query additional repositories that may contain key information that helps in making better security decisions. Employment status, security clearances, and external environmental factors are some example types of data that typically do not live in an LDAP server but can live in alternative formats/repositories, such as relational databases. OVD can be applied in such scenarios to tap into that information and expose it via LDAP to all the access decision points while keeping it in its current location (database) and current format (relational). FIGURE 10-10 Adding a plug-in for Active Directory 420 Part III: Identity Management In this section, we assume that a relational database table contains a user’s security clearance level in the enterprise. While this might initially seem like a military or intelligence scenario, businesses are starting to use the idea of security clearance levels to protect their financial records from being accessed inappropriately. So, for now we will assume a table with this simple column structure: SQL> desc user_clearance Name Null? Type USER_ID VARCHAR2(4000) CLEARANCE_CODE VARCHAR2(4000) CLEARANCE_LEVEL VARCHAR2(4000) The following shows the sample dataset in that table: SQL> select * from user_clearance; USER_ID CLEARANCE_CODE CLEARANCE_LEVEL HJAHANGIR NC Not Cleared PSACK S Secret SGAETJEN TS Top Secret DKNOX NC Not Cleared BWISE NC Not Cleared RWARK TS Top Secret TMUTH S Secret 7 rows selected. Before beginning the steps to “virtualize” a relational database table, you need to consider two design decisions that will impact the quality of the virtualization. First, you need to select an attribute that will be used to connect or relate the database records with the records in OVD. This is often the primary key of the database table where the attribute resides. In this case, you will use the USER_ID identifier (similar to an employee identity number in a HR application) that will connect the records. Next you need to decide where the virtual LDAP entries, originating from the relational database, should be presented in the LDAP tree. Oftentimes, the database records provide only part of an existing user’s profile, so the data needs to be joined with an existing LDAP entry that already represents the user. To get that unified user view, we need to do two things: 1. Create a new branch in the LDAP tree for all the user records from the database. 2. Join the new branch with the existing branch (this is covered in the upcoming section, “Joining Information in OVD”). Chapter 10: Oracle Directory Services 421 In this example, we intentionally chose a poor namespace (ou=DB,dc=oracle,dc=com) to demonstrate how OVD’s transformation capabilities can be used to clean up legacy namespace clutter without necessarily undertaking a “rip-and-replace” method. We can also hide the branch from the external LDAP clients, if we choose, by setting a visibility flag for that branch in OVD. The following shows the basic steps for “virtualizing” a database table: 1. Configure the JDBC driver library. Select the appropriate JDBC libraries installed with the Oracle Virtual Directory server using the OVD Library Manager interface, as illustrated in Figure 10-11. In this example, we selected the Oracle database’s ojdbc14.jar file for the Oracle-specific JDBC implementation. Note that the Library Manager in OVD Manager can be accessed by right-clicking the OVD Server, selecting Manage, and selecting Server Libraries. 2. Create and configure a database adapter in the OVD Manager as a new adapter. We will use the Oracle Thin Driver. Once the configuration information is properly entered, click Validate Connection, as shown in Figure 10-12. 3. Map the database table to the directory object by selecting the database table and the LDAP object class. FIGURE 10-11 Deploying Oracle JDBC drivers to OVD 422 Part III: Identity Management Note that if these are employees (that is, person records), you choose inetorgperson as the object class and uid or cn as the relative distinguished name (RDN). 4. Map the database columns to attributes of the object class. We map the USER_ID column to the uid attribute in the inetorgperson object class in Figure 10-13. At this point, OVD configuration is complete and you will have a virtual directory representation of your identity information from the database. You can test this by going back to the Server Browser panel in OVD Manager and refreshing any node in the Client View, as shown in Figure 10-14. This exercise illustrates the transformation of a relational database table into a directory tree, where we converted each record in the table to an entry under a certain namespace. While this type of integration can be technically interesting and useful, we are not quite done making the relational data accessible for our identity management purposes, because the new branch we created is in a different part of the directory tree than the rest of the user information that is coming from other LDAP servers. To unify the information from the database and the enterprise LDAP servers, such as OID and Active Directory, we need to apply another OVD function called joining using a join view adapter. FIGURE 10-12 Creating a database adapter in OVD Chapter 10: Oracle Directory Services 423 FIGURE 10-13 Mapping database to OVD FIGURE 10-14 Testing the database adapter in OVD . widely-used user data model standard in many web and client-server applications, so it makes sense to rationalize and map proprietary naming conventions to the standardized inetorgperson using. databases. OVD can be applied in such scenarios to tap into that information and expose it via LDAP to all the access decision points while keeping it in its current location (database) and current format. OVD Server, selecting Manage, and selecting Server Libraries. 2. Create and configure a database adapter in the OVD Manager as a new adapter. We will use the Oracle Thin Driver. Once the configuration