Pass-Through Authentication Understanding Oracle Virtual Directory Authentication

Understanding Oracle Virtual Directory Security 6-3 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 users 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.

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 adapters namespace, or when passcredentials is set to never. Oracle Virtual Directory also uses the adapters 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. Note: When a client binds without the use of a clear text password for example, with a certificate, the server cannot pass the users 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-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.