Priority Filters to Include and Filters to Exclude

Understanding Oracle Virtual Directory Routing 3-5 one scope apply to one level or sub tree searches and base searches would not be filtered. The default scope for an include filter is sub to filter out only queries involving an entire sub tree. To apply the filter applied for all scopes, set the scope to base, which means the filter is applied to base, one-level, and sub-tree searches. The default scope for an exclude filter is one to allow blocking of specific searches. To apply the filter for all scopes, set the scope to base. To apply the filter for just sub-tree searches, set the scope to sub. You can use the Filters to Include setting and the Filters to Exclude setting together to form a more complex set of conditions governing the adapters used in a client search operation. For example, imagine you want to allow specific types of searches through an LDAP Adapter deployed as a firewall. To allow only certain searches, you could use a Filters to Include setting such as: |mail=myorg.comuid=myorg.comsn=givenname=cn= This filter would block any search with terms other than mail, uid, sn, givenname, or cn and allow only searches involving one or more of these terms. For example cn=Jim Smith is acceptable, while uid=smithoracle.com is not acceptable since it does not end in myorg.com Although most adapter configurations use simple search terms, a more complex example may better illustrate how the logic is applied. Consider the following filter example: Client Search Command ldapsearch -b dc=oracle,dc=com -s sub |sn=user2cn=user2b Routing Filter: |uid=cn=sn= The routing filter indicates that if the client search filter contains an sn attribute and either a uid or cn term, than a match is made. In this example, without regard to other conditions, the adapter would be selected if the given routing filter were assigned to the Filters to Include setting and would be deselected if assigned to Filters to Exclude setting because the client filter includes an sn term and a cn term which fulfills the logic of the filter.

3.2.3 DN Matching

DN Matching is most often used when you want to have adapters sharing the same adapter root and you need a way to arbitrate which entries belong to which adapter. DN Matching enables you to exploit the differences in naming that might occur between two proxied sources. For example, in a large scale deployment you may want to divide the entries based on the alphabet. DN Matching enables you to select alphabetic ranges and then allows Oracle Virtual Directory to select adapters based on range match. Thus, if you divided names into three ranges, users with IDs beginning A through J could be one directory, K through R might be another directory, and S through Z might be the final directory portion. Another useful scenario for DN Matching is federating Microsoft Active Directory users with users in an external directory such as Open LDAP or some other directory. If the users in Open LDAP have relative distinguished names RDNs that are based on the uid attribute and Active Directory has user entries based on the cn attribute, 3-6 Oracle Fusion Middleware Administrators Guide for Oracle Virtual Directory then you can establish a regular expression that selects adapters based on the RDN type. For Active Directory Adapter, the DN match might be: .cn=[a-z0-9] For Open LDAP, the DN match might be: .uid=[a-z0-9] By using DN Matching, Oracle Virtual Directory can effectively manage overlapped adapters by exploiting the differences in the existing sources.