414 Part III: Identity ManagementInitializing the Virtual LDAP Tree Using a Local Store Adapter Before any physical information is presented through a virtual directory, you need to de
Trang 1414 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
Trang 2Chapter 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
Trang 3416 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
Trang 4Chapter 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
Trang 5418 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
Trang 6Chapter 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
Trang 7420 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”)
Trang 8Chapter 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
Trang 9422 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
Trang 10Chapter 10: Oracle Directory Services 423
FIGURE 10-13 Mapping database to OVD
FIGURE 10-14 Testing the database adapter in OVD