16
Directory-Based Application Security

This chapter discusses how you can exploit the way Oracle Internet Directory stores access control policies to secure applications in a large enterprise and in hosted environments. This chapter contains these topics:

• Delegated Directory Administration

• Application-Specific Access Control

• Directory Domains and Roles

Delegated Directory Administration

Because Oracle Internet Directory stores access control policies as LDAP attributes, you can set metapolicies controlling who can modify them. This enables a global administrator to assign privileges to administrators of specific subtrees--for example, to administrators of applications in a hosted environment. Similarly, a global administrator can delegate to departmental administrators access to the metadata of applications in their departments. Department administrators can then control access to their department applications.

Thus, you can implement access control on two levels:

• Authorization of users

  In this case, the directory stores access control policies that external applications then read and enforce. When a user tries to perform an operation by using an application, the application verifies that the user has the correct authorization to perform the operation.

• Authorization of administrators

  In this case, the directory serves as the trusted point of administration for all application-specific access control polices. To govern who can administer the access control policies of specific applications, you set access control policies at the directory level for these applications. Then, when a user attempts to change an application-specific access control policy, the directory verifies that the user has the correct authorization to make that change.

Application-Specific Access Control

Figure 16-1 shows the relationship between directory access control and the application-specific access control mechanisms in a hosted environment.

Figure 16-1 Directory Access Control and Application-Specific Access Control

Text description of the illustration oidag037.gif

Directory Domains and Roles

Figure 16-2 illustrates the various domains and the roles associated with them in the directory.

Figure 16-2 Directory Domains and Roles in a Hosted Environment

Text description of the illustration oidag041.gif

In Figure 16-2, each triangle represents a portion of a DIT.

• The outermost triangle represents the entire directory. The directory administrator has privileges extending across the entire directory.

• Immediately inside the outermost triangle, another triangle represents the service provider administrative domain. In this domain, privileges to add new entries are delegated to the service provider's administrators.

• Inside the service provider administrative domain, privileges can be further delegated based on the ownership of directory information. For example, the delegation can depend on whether the information is private to a specific subscriber or global to the service provider.

Figure 16-2 shows only a single subscriber represented in the directory. In reality there are multiple subscribers, each with its own domain requiring protection from the others.

Some of the protection domains in this model are:

• Entire directory

• Service provider administrative domain

• Service provider-specific directory information tree

• Subscriber-specific subtree

• Application-specific footprint in the directory

• User-specific information

These protection domains are supported by the following roles, which enable the service provider or subscriber to customize access control.

• Global Administrative Roles

  These roles have rights to perform activities that span the entire directory.

• Subscriber-Specific Roles

  These roles are limited to the directory trees specific to the subscribers.

• Application-Specific Roles

  When hosting directory-enabled applications, it is not necessary to represent all application-specific roles in the directory. However, it is better that applications, when representing roles that directly affect their directory footprint, follow the delegation model recommendations described earlier. This enables applications to leverage the directory-based delegation model when granting directory-specific privileges to users.