I2A2 LDAP Search Operations
The LDAP search operation is a lookup request. The PUID to be found can be identified in the RDN or in a filter.
While all three I2A2 DBMs can look up PUIDs, the authenticator and authorizer DBM can only do so when given an alias or a PUID as a key. The reflector DBM can also look up PUIDs by common name or by a common name regular expression.
The I2A2 DBM is identified in the first component of the base DN:
ou=authenticate identifies the authenticator DBM.
ou=authorize identifies the authorizer DBM.
ou=identify identifies the reflector DBM.
I2A2 LDAP Attributes
The I2A2 LDAP attributes are described here.
Alias or PUID as a Search Key
When the alias to a PUID or the PUID itself is a search key, the key may be supplied in the RDN or in a filter.
Here are some RDN examples:
Here are some filter examples:
Common Name as a Search Key The I2A2 reflector DBM can support searches with the common name as
a key. The reflector can also support searches by a common name regular expression. Other name attributes,
such as given name or surname, can be used in search filters, but the RDN or the filter must always supply a
common name attribute and its value.
When the search key is a common name, the base DN must specify the reflector DBM (ou=identify). The common name may be supplied in the cn attribute and value of the RDN or in a filter, but it must be supplied in one or the other. If it isn't supplied in either the I2A2 LDAP protocol converter will reject the search request and return a "no search criteria" error message.
Here's an RDN example, accompanied by the DN for the reflector:
cn=alfred e newman,ou=identify,dc=purdue,dc=edu
Here's an example where the DN specifies the I2A2 reflector DBM and a filter specifies the common name:
Filter: (cn=alfred e newman)
While cn is the only attribute supported in an RDN, the givenName and sn attributes may also be used in an accompanying
filter as long as cn is present in the RDN or filter, too. See Common Name Regular Expression as a Search
Key for an example.
Common Name Regular Expression as a Search Key The LDAP protocol has a limited regular expression facility called sub-strings. They are expressed with the familiar '*' wild-card character and may be used at the beginning or end of attribute values.
I2A2 LDAP allows LDAP sub-string indicators to be used in common name attributes. It converts the LDAP substring '*' character into the UNIX regular expressions ".*" (a dot, fllowed by an asterisk).
When a sub-string is specified in a cn attribute, additional search criteria may be specified in givenName and sn attributes of an accompanying filter. Here's an example that specifies a search for the last name "newman" and the first name "alfred" or "alfonso". (Note that cn is required in the RDN or the filter.)
CAUTION: regular expression searching in the reflector DBM is not particularly efficient. It can and does regularly
exceed the time limit expressed to it in the LDAP protocol. If you need to do complex searching for the names of Purdue people,
consider using the more efficient lookup facilities of the Purdue Electronic
Search Return Values A successful search returns the "success" LDAP response and attributes that describe the PUID that was found. A failed search returns the "failure" LDAP response and may return an optional explanation.
These values (with examples) are returned for all searches:
Common name: cn=alfred e newman
Given name: givenName=alfred
User ID (alias): uid=foobar
This value is returned when a characteristic expression attribute (chx) is supplied in an authorizer DBM search request (ou=authorize):
Characteristic expression value: chv=(1234&8765)=0