6 Understanding Oracle Virtual Directory Security

This chapter describes Oracle Virtual Directory security and includes the following sections:

Section 6.1, "Overview"
Section 6.2, "Understanding Oracle Virtual Directory Authentication"
Section 6.3, "Understanding Oracle Virtual Directory Access Control"
Section 6.4, "Understanding Wallet and Certificate Management"

6.1 Overview

Oracle Virtual Directory supports multiple tiers of access control and authentication. For remote directories accessed through adapters, Oracle Virtual Directory supports the security inherent in those systems. Depending on the adapter used and its capabilities, a passcredentials option can be set to determine if end-user binding credentials should be passed to the remote directory for authentication and access control enf orcement, as shown in Figure 6-1:

Figure 6-1 Oracle Virtual Directory Multi-Layered Access Control and Authentication

Access control and authentication with passcredentials.

6.2 Understanding Oracle Virtual Directory Authentication

This section describes Oracle Virtual Directory authentication and contains the following sections:

Pass-Through Authentication
CRAM-MD5 and SASL Binding
Proxy Account Authentication
Client Certificate Authentication

6.2.1 Pass-Through Authentication

When an adapter has pass-through mode enabled and a user is to be authenticated to Oracle Virtual Directory, Oracle Virtual Directory uses the user-id and password credentials it receives to log in to the remote directory on the users behalf (for password authentication only). If the authentication (bind) to the remote directory fails, Oracle Virtual Directory will fail the attempted bind by the user. In this mode, the remote directory is responsible for confirming a user's credentials.

When passcredentials is set to never (or is not supported by the selected adapter), Oracle Virtual Directory must perform the authentication of clients itself. In order for this to work, passwords in external directories must be stored in clear text or must use the CRYPT, SHA, or SSHA one-way encryption hash. For Oracle Virtual Directory to determine which encryption hash is being used, a prefix of the form {crypt} must be applied to the encrypted text. If the proxied source does not use this format, you must set up a mapping rule to define it. The mapping rule adds the prefix telling Oracle Virtual Directory how to handle a particular encryption format. If no prefix is present, a normal text comparison is made.

In passcredentials never mode, authentication is completed by Oracle Virtual Directory by performing the hash algorithm (specified in the value returned from the adapter) of the password provided by the user and comparing the result with the value returned from the adapter.

Note:

When a client binds without the use of a clear text password (for example, with a certificate), the server cannot pass the user's credentials to the proxied directory. The Oracle Virtual Directory uses the configured adapter account to perform the bind verification and perform the LDAP service requested. This is equivalent to what happens when passcredentials is set to never.

6.2.2 CRAM-MD5 and SASL Binding

CRAM-MD5 is a challenge-response authentication mechanism (CRAM) based on the HMAC-MD5 MAC algorithm, a widely used cryptographic hash function with a 128-bit hash value (or "MD5"). CRAM-MD5 is a Simple Authentication and Security Layer (SASL) bind mechanism used to authenticate to Oracle Virtual Directory.

If the client supports CRAM-MD5, you can use it to keep passwords secret over the wire without using SSL. However, the CRAM-MD5 SASL mechanism requires that the server has a plain text version of the password that it uses to exchange information other than the password that lets the server determine whether a given password provided by an LDAP client is valid. If this mode is used, passwords must be stored in clear text in all local (standard) and proxied sources.

6.2.3 Proxy Account Authentication

Oracle Virtual Directory uses a proxy (or default) account when authenticating users for which no password is available, when proxying users whose bind DN is outside of the adapter's namespace, or when passcredentials is set to never. Oracle Virtual Directory also uses the adapter's proxy user-id and password to authenticate both the Oracle Virtual Directory Root Manager Account and Anonymous to the connected LDAP Adapter directory. The default account is also used for users who authenticate using certificates. Therefore, when passcredentials mode is enabled, it is important to understand that the default account should be set to a non-privileged account (for example, anonymous) in remote directory as there are many conditions when the proxy account may be required to handle accounts that cannot be mapped to the current adapter.

6.2.4 Client Certificate Authentication

Oracle Virtual Directory supports the ability for clients to authenticate to the virtual directory using X.509 digital certificates. The LDAP clients must support SSL and SASL to authenticate to the virtual directory using X.509 digital certificates. The following are the two modes in which SSL authentication works:

Using client certificates as a way to secure the connection but not to authenticate to the actual directory
Using SASL to bind to the Oracle Virtual Directory using the certificate

The following is a list of guidelines for using client certificates for authentication:

If using certificates to bind to Oracle Virtual Directory, it is only used to authenticate to Oracle Virtual Directory, not to any back-end data-store. Public Key Infrastructure (PKI) prevents authentication to any back-end data-store because only the LDAP client has access to its private key, which is required to do client certificate authentication. Therefore, all Oracle Virtual Directory operations to the back-end data-store are performed as the Proxy DN account when using the LDAP Adapter.
Certificates contain their own distinguished names (DNs), which sometimes do not match the DN of the user they are actually binding as. In these cases, you may have to map the DN of the certificate to the DN of an user in Oracle Virtual Directory for your Access Control Lists to work properly. You can use a plug-in to accomplish this mapping.
Oracle Virtual Directory accepts any certificate issued by the root CAs stored in its keys.jks file.

6.3 Understanding Oracle Virtual Directory Access Control

Oracle Virtual Directory provides granular access controls that can be applied uniformly across all connected data stores and which are compliant with the Internet Engineering Task Force's RFC 2820, Access Control Requirements for LDAP. The access control rules are modeled on the IETF's internet draft titles LDAP Access Control Model for LDAPv3, (March 2, 2001 draft).

Note:

Oracle Virtual Directory provides virtualized abstraction of one or more enterprise data sources into a single directory view. Accordingly, Access Control Lists (ACLs) and adapter namespaces are independent of each other. If you remove an entry, the ACLs associated with the entry are also removed. However, the ACLs associated with an entry are not affected if you change the root value of an adapter. ACLs and adapter namespaces must be configured independently of each other.

This section describes Oracle Virtual Directory access control and contains the following sections:

Source Directory Access Control
Oracle Virtual Directory Access Control
Access Control and Groups
Oracle Virtual Directory Access Control Components
Oracle Virtual Directory Access Control List Enforcement

6.3.1 Source Directory Access Control

As a client to a remote directory, Oracle Virtual Directory must conform to the authorization rules enforced in the remote directory. The rules applied depend on what user context has been passed to the remote directory, that is, what account is Oracle Virtual Directory using to connect to the proxied directory with.

If you enable the passcredentials option, the remote directory enforces rules according to the user context Oracle Virtual Directory presents to the remote directory. Oracle Virtual Directory presents appropriately translated data results and errors back to the user. For example, if an access denied message is returned, Oracle Virtual Directory returns that message to the client. If data is filtered due to access control, Oracle Virtual Directory takes the filtered data, applies any configured translations, and then presents that data to the user.

If the passcredentials option is not enabled, the remote directory perceives only the proxy user for all requests and applies the same authorization regardless of which user has bound to Oracle Virtual Directory.

Regardless whether the passcredentials option is enabled or disabled, Oracle Virtual Directory provides its own access control and authorization.

6.3.2 Oracle Virtual Directory Access Control

Oracle Virtual Directory supports access control across its entire virtual directory namespace by storing access control information. This information is maintained automatically by intercepting requests to modify the entry DN or subtree DN of the DIT. Because Oracle Virtual Directory Access Control Lists (ACLs) are defined in the namespace of the virtual directory and not in any of the directories connected by using the adapters, a single ACL can be defined that governs access to data across several adapters.

When an entry belongs to a proxied LDAP directory using the same access control draft standard, it is impossible to modify access controls within that source directory using Oracle Virtual Directory because Oracle Virtual Directory intercepts the modification and applies it to its own ACI values for the entry. In this case, modification to these entries must be made directly to the source directory. Normally this is not an issue since directory servers from different vendors use different attributes for storing access control information.

6.3.3 Access Control and Groups

When using groups as subjects for access control it is important to consider where groups are located and how adapter translation impacts them. For each LDAP Proxy Adapter defined, make sure you have the DN Attribute List value defined. This value defines the list of attributes that must be mapped to the virtual directory tree in addition to the entry DN. With an access control that depends on an attribute value containing a DN, the value must be correctly mapped.

To have a group that has members from multiple adapters, for example, from both a Local Store Adapter and an LDAP Adapter, place the group in the Local Store Adapter adapter namespace, that is, the local store of the virtual directory. If the group is placed within an external LDAP directory and it contains members that are not present in that directory, translation may not work as expected because the entries that are not in the external directories namespace have no context.

6.3.4 Oracle Virtual Directory Access Control Components

This section describes Oracle Virtual Directory access control components and contains the following sections:

Overview
Access Control Scope
Access Control Rights
Attribute Access Control
Access Control Permissions
Access Control Subjects

6.3.4.1 Overview

To create an Oracle Virtual Directory ACL you:

Configure an Access Control Point, that is, identify the location where the ACL will be applied. Typically the Access Control is a distinguished name, but can also be root to stand for the base of the tree.
Configure the policy for both Structural Access Items, that is, entire entries in the virtual directory tree, and for Content Access Items, that is, the attributes of the entry.

Note:

If an entry being accessed or modified on the Oracle Virtual Directory server does not equal or reside below the ACL Access Control Point, the given ACL is not evaluated further. If the entry being accessed or modified does equal or reside below the ACL Access Control Point, the ACL scope setting is evaluated.

6.3.4.2 Access Control Scope

Oracle Virtual Directory defines two types of scope for access control: Entry and Subtree. Figure 6-2 illustrates how these scope components operate:

Figure 6-2 Oracle Virtual Directory Access Control Scopes

Relationship between Entry and Subtree scopes.

As shown in Figure 6-2, location and scope are related in that location indicates the position on the DIT where scope is evaluated. In the entry portion of Figure 6-2, the ACL applies only when the directory entry (DN) being accessed or modified is the same DN indicated by Location 1. In the subtree portion of Figure 6-2, all DNs beginning from Location 1 and moving downward are affected by the ACL with subtree scope. The only endpoint for a subtree scope occurs when, for a given ACL, another ACL declared at a point below the first ACL (Location 2), alters the rules established by the first ACL.

Entry scope is often used with various subjects and deny settings. It is especially useful when a single entry contains more sensitive information than the entries around it or even below it and must be kept private. When two scope rules exist that differ only in their scope type, an entry scope takes precedence over a subtree scope.

6.3.4.3 Access Control Rights

There are two Oracle Virtual Directory access rights for each permission: grant and deny. The decision whether to grant or deny a client access to a particular piece of information is based on many factors related to the access control rules and the entry being protected. Throughout the decision making process, the following guiding principle are used:

Specificity: more specific rules override less specific ones, for example, specific client DN in an ACL takes precedence over group reference.
Deny: the default when access control is enabled and there is no access control information granting or denying the operation.
Grant: the default when access controls are disabled in Oracle Virtual Directory.
Entry vs. Subtree: The entry scope takes precedence over the subtree scope, given the subject and attributes have the same specificity.

The following is the order of precedence Oracle Virtual Directory uses in evaluating ACLs which differ only in the type of subject:

Specific DN or IP Address
This
Groups
Subtree
Public

Note:

If two ACLs differ only by their grant/deny property, the resulting permission is a deny regardless of the order in which the ACLs are added. For example, the following two ACLs will result in a deny for Search(s) and Read(r) of all attributes for public:

deny:s,r#[all]#public:
grant:s,r#[all]#public:

6.3.4.4 Attribute Access Control

The attributes component is strongly linked to the permissions component because it determines whether permissions apply to directory entries as a whole, by selecting Entry, or to some or all of their attributes, by identifying specific attributes.

6.3.4.5 Access Control Permissions

The permissions that apply either to entire entries or to their attributes parallel the type of LDAP operations that can be performed. Each of the LDAP access permissions are discrete: one permission does not imply another permission. When configuring ACLs it is typical to have two ACLs relating to the same location because there is a requirement to separate permissions for the individual attributes (attribute permissions) from those of the entry itself (entry permissions). Attribute permissions require an attribute component of either * (meaning all attributes), or a list attributes for which the attribute permissions apply. Entry permissions require an attribute component of entry.

Structural Access Permissions

Structural Access permissions are for entire entries in the virtual directory tree. The following is a list and description of each Structural Access Item permission:

Add (a): permits an entry to be added below the given location. For a client application to add an entry, the make attribute permission must also be granted to add at least the mandatory attributes for each objectclass.
Delete (d): permits an entry to be deleted from the DIT, regardless of existing attribute permissions within the entry.
Rename DN (n): permits an entry to be renamed or moved.
Browse DN (b): permits an entry to be browsed. If granted, permits entries to be accessed using directory operations that do not explicitly provide the name of the entry.
Return DN (t): permits the entry's DN to be disclosed in the result of the LDAP operation.

Granting Rename DN is necessary for an entry to be renamed with a new Relative DN (RDN). However, you must take into account that there will be consequential changes to the distinguished names of its subordinate entries, if any. Renaming an entry does not require any prerequisite permissions of its contained attributes, including the attributes of RDN itself.

Further, note that there are two conditions under which a rename takes place: (1) the rename does not change the name of it's superior DN (thus, a literal renaming of the RDN) and (2) the rename relocates the DN and its subordinates in DIT, thus the entry gets a new superior DN (a move).

For any type of rename to take place, the DN to be moved must have the Rename DN permission; the target DN (under which the new entry is placed) must have both Add and Rename DN permission.

Unless other requirements forbid, it is common to specify entry permissions: Browse DN and Return DN for most locations to allow full retrieval of the data in the directory. Similarly, it is common to grant both write and obliterate permissions for locations that may require data modification.

Content Access Permissions

Content Access permissions are for entry attribute. The following is a list and description of each Content Access Item permission:

Read: permits attribute values to be read in a read or search operation.
Write: permits attribute values to be modified or added in a modify operation.
Obliterate: permits attribute values to be deleted in a modify operation.
Search: permits attributes to be searched for specified values in a search operation.
Compare: permits attributes to be compared in a compare operation.
Make/Create: permits new attributes to be made on a new entry below the identified entry.

The Make/Create attribute permission is required for all attributes in an entry when it is created; it is typically associated with the Add entry permission.

Unless other requirements forbid, it is common to specify attribute permissions: search, read, and compare for most locations to allow full retrieval of the data in the directory. Similarly, it is common to grant both write and obliterate permissions for locations that may require data modification.

Write and obliterate have no bearing on an add operation; make has no bearing on a modify operation. Since a new entry does not yet exist, the add and make permissions needed to create it must be granted on the new entry's parent. This differs from write and obliterate, which must be granted on the entry being modified. The make permission is distinct and separate from the write and obliterate permissions so that there is no conflict between the permissions needed to add new children to an entry and the permissions needed to modify existing children of the same entry.

To replace attribute values by using the modify operation, the entry must have both write and obliterate permissions enabled for the attribute.

6.3.4.6 Access Control Subjects

The subject of an ACL determines whom it applies to. Oracle Virtual Directory utilizes a variety of possible subject types, which take the client credential, whether user-supplied or from the proxy account (for example, binddn), and apply it under the following conditions:

Figure 6-3 Oracle Virtual Directory ACL Subjects

Specific DN: ACL applies when the client DN credential is compared and matches the value you identified in the ACL settings.
This: ACL applies to the client whose credential matches that of the entry being accessed.
Subtree: ACL applies when the client credential falls in or under the DN specified in the subject.
Group: ACL applies when the DN specified by the subject component is looked up and the client credential is a member of the group determined by one of three objectclasses: groupOfUniqueNames, groupOfNames, groupOfUniqueURLs. The first two types of groups specify static lists of users: for groupOfUniqueNames a uniquemembers attribute must match the client credential; for groupOfNames a member attribute must match the client credential. The third group type, groupOfUniqueURLs, deals with dynamic groups and requires the client credential to match at least one of the DNs obtained by performing the search specified by the value of the memberurl attribute.
Public: ACL applies to any client connected to the directory, whether they are authenticated or not.
IP Address: ACL applies when the client IP address is compared and matches the value you identified in the ACL settings.

The following are notes and examples for each of the ACL subjects:

Specific DN

The Specific DN subject is typically used to grant or deny access to a specific client, such as proxy binddn, over part of the DIT. When a user binds anonymously, the proxy credentials are sent to the server and it would not be wise to allow the proxy binddn to view or modify sensitive entries or attributes in the DIT.

Example (if binddn=cn=service):

	ACL1	ACL2
location	ou=security, o=oracle.com	ou=security, o=oracle.com
scope	subtree	subtree
rights	deny	deny
permissions	read, search, make, write, obliterate	add, delete, renameDN, browseDN, returnDN
attributes	[all]	[entry]
subject	specificDN=cn=service	specificDN=cn=service

This

The This subject is generally used to permit any given client located somewhere in the DIT the ability to both read and modify their personal information, such as userpassword, postaladdress, telephonenumber, and so on. Another ACL is usually used to deny such access to the public at large

Example:

	ACL1	ACL2	ACL3
location	o=oracle.com	o=oracle.com	o=oracle.com
scope	subtree	subtree	subtree
rights	deny	grant	grant
permissions	read, compare	read	write, obliterate
attributes	userpassword	userpassw	userpassword, postaladdress
subject	public	this	this

Subtree

The Subtree subject is useful when the client credential may be found anywhere within a subtree of the DIT. Typically, this subtree might contain nothing but privileged accounts under closely related branches.

Example:

cn=jbowen, ou=eng_admins, ou=admins, ou=security, o=oracle.com

An admin with preceding DN must authenticate. One possible ACL implementation that would authenticate this admin, and other similarly-privileged admins, using subtree would be:

	ACL1	ACL2
location	o=oracle.com	o=oracle.com
scope	subtree	subtree
rights	grant	grant
permissions	read, search, make, write, obliterate	add, delete, renameDN, browseDN, returnDN
attributes	[all]	[entry]
subject	subtree=ou=admins, ou=security, o=oracle.com	subtree=ou=admins, ou=security, o=oracle.com

Group

The Group subject is most often chosen for granting specific rights and permissions to differing categories of users because it allows the greatest flexibility in specifying where in the DIT to look for their entries to perform the authentication.

For example, an admin with the credential: cn=jbowen, ou=admins, ou=security, o=oracle.com must authenticate. One possible ACL and entry combination which would authenticate this admin using the Group subject with objectclass groupOfURLs and attribute memberURL would be:

	ACL1	ACL2
location	o=oracle.com	o=oracle.com
scope	subtree	subtree
rights	grant	grant
permissions	read, search, make, write, obliterate	add, delete, renameDN, browseDN, returnDN
attributes	[all]	[entry]
subject	group=ou=sales, ou=depts, o=oracle.com	group=ou=sales, ou=depts, o=oracle.com

The DN in the subject component which would be examined for objectclasses specifying groups is:

dn: ou=sales, ou=depts, o=oracle.com
objectclass: organizationalUnit
objectclass: groupofurls
ou=sales
memberurl: ldap:///ou=admins,ou=security,o=oracle.com?sub?(objectclass=inetOrgPerson)

In the preceding DN, the LDAP search specified by the memberurl attribute would contain at least the following DN, which would then authenticate the client credential:

dn: cn=jbowen, ou=admins, ou=security, o=oracle.com
objectclass: inetOrgPerson
cn: jbowen
userpassword: xyz123

Public

An ACL which uses Public, usually with grant, wants to give access to the DIT to the widest potential client base. Generally, this is done to the [root] location with an entry scope and then done specifically to the base of the tree with another ACL with scope entry and an ACL with scope subtree. Usually, other ACLs are also added to restrict specific parts of the tree and specific attributes, such as userpassword, from viewing or modification by the public.

For example:

	ACL1	ACL2	ACL3	ACL4
location	[root]	[root]	o=oracle.com	o=oracle.com
scope	entry	entry	subtree	subtree
rights	grant	grant	grant	grant
permissions	search, read	browse, return	search, read	browse, return
attributes	[all]	[entry]	[all]	[entry]
subject	public	public	public	public

IP Address

ACL applies when the client IP address is compared and matches the value you identified in the ACL settings. The IP Address value can be an IP mask.

For example:

	ACL1	ACL2
location	ou=security, o=oracle.com	ou=security, o=oracle.com
scope	subtree	subtree
rights	deny	deny
permissions	read, search, make, write, obliterate	add, delete, renameDN, browseDN, returnDN
attributes	[all]	[entry]
subject	specificIP=192.168.1.*	specificIP=192.168.1.*

6.3.5 Oracle Virtual Directory Access Control List Enforcement

The following is a summary of how Oracle Virtual Directory enforces ACLs:

The first ACL related to the attribute being examined is known as the matched ACL. The matched ACL assumes the highest priority of enforcement while Oracle Virtual Directory moves down the order and evaluates each and every subsequent ACL.
The enforcement of the matched ACL changes only in a few conditions, such as when the scope specified in a subsequent ACL is more specific, that is deeper to the DIT, or when the subject type is changed, for example, from public to this.
Oracle Virtual Directory denies access of an ACL if the scope of the matched ACL and a subsequent ACL are the same and either the matched or subsequent ACL denies permission to the attribute being considered.
Oracle Virtual Directory sequentially evaluates every ACL listed while descending through the last ACL listed until an enforcement decision is reached after all ACLs are evaluated.

6.4 Understanding Wallet and Certificate Management

In Oracle Virtual Directory 11g Release 1 (11.1.1), you can manage wallets and certificates using Oracle Enterprise Manager Fusion Middleware Control. Refer to the Oracle Fusion Middleware Application Security Guide for complete information on managing wallets and certificates for Oracle Virtual Directory.