Cache Plug-In Understanding the General Purpose Plug-Ins

Understanding Oracle Virtual Directory Plug-Ins 4-21 Oracle Virtual Directory is designed to function without the Cache plug-in and often it is not necessary because many applications either cache results on their own, or because most enterprise source systems already cache data. Also, because Oracle Virtual Directory is often used in secure environments, keeping a cache exposes security elements, such as if an employee is terminated and their user result is still in the cache. The Cache plug-in can greatly improve performance for applications where queries are highly repetitive and can be configured to run any where within Oracle Virtual Directory. The Cache plug-in can be executed globally or within the context of a single adapter, and can also be restricted to specific namespaces using namespace filtering. If a query is repeated by the same user and the same attributes or a subset of attributes are requested, the cache returns its results instead of Oracle Virtual Directory retrieving the information from the source. For example, consider the following two theoretical queries where the client changes the search attributes in Query 2: Query 1 ■ Bind as : cn=Example User,cn=users,dc=mycompany,dc=com ■ Base of : dc=mycompany,dc=com ■ Query of : uid=jdoe ■ Attributes : cn,mail Query 2 ■ Bind as : cn=Example User,cn=users,dc=mycompany,dc=com ■ Base of : dc=mycompany,dc=com ■ Query of : uid=jdoe ■ Attributes : telephonenumber,manager By using the Cache plug-in, Oracle Virtual Directory does not treat Query 1 and Query 2 as two separate queries and does not search the back-end source twice. Oracle Virtual Directory requests all the attributes for matching entries in Query 1, but only returns the attributes requested by the client and keeps an in-memory copy of the search results in its cache. The Cache plug-in can also be configured to allow cache hits to be shared between users. Sharing cache entries between users should not be used unless passcredentials is not being passed to back-end sources and Oracle Virtual Directory is solely responsible for security enforcement. Note: If you use the Cache plug-in, the cache timeout should be kept small to avoid cache update problems in cases such as these. Note: Oracle Virtual Directory retrieves only the attributes which the bound user has access to based on the back-end source repository Access Control Lists ACLs, Oracle Virtual Directory ACLs, and adapter routing rules. 4-22 Oracle Fusion Middleware Administrators Guide for Oracle Virtual Directory The Cache plug-in periodically reviews the cache and checks for any expired results or entries that have been invalidated by a previous modify transaction. If the cache quota is exceeded, the Cache plug-in attempts to trim memory by purging the queries that were least recently used.

4.2.12.1 Configuration Parameters

The following is a list and description of the Cache plug-in configuration parameters: storeallattrs Controls whether the Cache plug-in silently requests all attributes. Supported values are 0 disable or 1 enable. By default, the storeallattrs parameter is disabled 0. bysubject Indicates whether cache results are shared between subjects. Supported values are 0 or 1. A value of 0 indicates results are shared between subjects and a value of 1 indicates that results are not shared between subjects. The default value is 1. maintenanceinterval The amount of time in seconds between when the cache manager checks for expired queries. The default value is 60. size The maximum number of entries that may be cached at any one time. The default value is 10000. maximumage The maximum age or time, in seconds, that any queryentry can be stored in the cache. The default value is 600. maxresultsize The maximum number of entries that may be cached for any particular query. The default setting is 1000. trimsize When the maximum cache size is exceeded, this parameter indicates the amount by which the cache manager must reduce the balance. The default value is 10000. zeroresults Indicates whether to cache query results containing zero entries. Supported values are 0 and 1.

4.2.13 ObjectClass Mapper Plug-In

The ObjectClass Mapper plug-in is a general mapping plug-in that can make one objectClass, such as user, appear like another objectClass, such as inetOrgPerson. This Note: Careful planning should take place when sharing cache hits between users as it may then be possible for one user to see something they should not, since they may have access to a cache result from a more privileged user. Note: When necessary, trimming is done by purging expired queries first followed by queries in order of least recent use. Understanding Oracle Virtual Directory Plug-Ins 4-23 ability is useful when an application is expecting a particular objectClass and attributes but the directory does not support that objectClass or attributes. The ObjectClass Mapper plug-in can perform several different types of manipulation based on configuration parameters you select, including: ■ attribute mapping ■ objectclass mapping ■ adding attributes conditional on objectclass ■ removing attributes ■ filtering auxiliary classes ■ handling activation and deactivation Where attribute mapping relationships occur, the prefix client- indicates client side and source- indicates data source side. For example, mapping Active Directory server user to represent it as InetOrgPerson would imply that Active Directory is the source side and InetOrgPerson is the client side.

4.2.13.1 Configuration Parameters

The following is a list and description of the ObjectClass Mapper plug-in configuration parameters: directoryType The directory type to use when performing user activation. Supported values are SunOne, eDirectory, ADAM, and ActiveDirectory. For example: Parameter Name: directoryType Parameter Value: ActiveDirectory activationAttribute Use the activationAttribute parameter when an application has no knowledge of the underlying directorys user activation system. The activationAttribute parameter informs Oracle Virtual Directory which incoming attribute contains the user activation flag, which is then mapped to a directory specific attribute and flag. For example: Parameter Name: activationAttribute Parameter Value: myuseraccountcontrol deactivationValue Comma separated list of attribute values specified in activationAttribute that indicate this user should be marked as inactive. activationValue Comma separated list of attribute values specified in activationAttribute that indicate this user should be marked as active. mapObjectClass An objectClass to be mapped in the form of client-ObjectClass=source-ObejctClass . For example: Parameter Name: mapObjectClass Parameter Value: inetOrgPerson=user You can use the mapObjectClass parameter multiple times for multiple mappings.