Proxy Account Authentication Understanding Oracle Virtual Directory Authentication

6-4 Oracle Fusion Middleware Administrators Guide for Oracle Virtual Directory

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 Forces RFC 2820, Access Control Requirements for LDAP. The access control rules are modeled on the IETFs internet draft titles LDAP Access Control Model for LDAPv3, March 2, 2001 draft. This topic 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 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. Understanding Oracle Virtual Directory Security 6-5

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.