Simple wildcards can be used in the user or user-group selector values:

For example, the following selector matches to user names jdoe and jdox, but not to jdoex:

<selector>
  <user name="jdo?" />
</selector>

Regular expressions can be used in selectors to define ranges of values instead of defining each possible value separately. Each regular expression attribute (regexp, fqdn-regexp or name-regexp) always contains a single pattern, never lists of patterns. The whole string must be matched for a match to be successful.

Regular expressions are applicable for example with user names and user group names. For example, the following selector matches to all user names that consist of (any) 4 letters and (any) 3 numbers:

<selector>
  <user name-regexp="[[:alpha:]]{4}[[:digit:]]{3}" />
</selector>

By default, the regular expressions are matched case-insensitively. Case-sensitive matching can be activated by adding "(?-i)" to the pattern. This instructs the regexp engine to turn off case-insensitive matching for the following string. It can be turned back on with "(?i)".

	Note
	Design the regular expressions very carefully in order to avoid unintentional matches.

For the syntax of the regular expressions, refer to the description of the Egrep Syntax in the Tectia Client User Manual. Do not use the control characters elsewhere in the values, but if it is unavoidable, carefully escape the relevant characters. The escape character is backslash "\". A literal backslash can be matched with "\\".

Multiple selector elements are in an OR relation (one of the selector elements must match for the parent element to match). For example, the following block matches if either the IP address is 192.168.0.3 or the user ID is 1001:

<selector>
  <ip address="192.168.0.3" />
</selector>
<selector>
  <user id="1001" />
</selector>

Selector attributes in the same selector element are normally in an AND relation (all attributes must match for the element to match). For example, the following block matches if both the IP address is 192.168.0.3 and the user ID is 1001:

<selector>
  <ip address="192.168.0.3" />
  <user id="1001" />
</selector>

However, selector attributes in the same selector element matching to the same attribute type are in an OR relation to each other. The following three examples produce the same result, either the user name exa or mple matches:

<selector>
  <user name="exa" />
  <user name="mple" />
</selector>

<selector>
  <user name="exa" />
</selector>
<selector>
  <user name="mple" />
</selector>

<selector>
  <user name="exa,mple" />
</selector>

An empty selector always matches:

<selector />

Also, typically, if an element accepts selectors, but none are given, the element is assumed to have an empty selector, which will then always match.

Normally when the server tries to match to a selector attribute for which the respective data has not been defined (the data is not available to the server), the selector matching process ends in error, effectively terminating the connection attempt. This happens, for example, in the following cases:

The allow-undefined attribute can be used in all selector sub-elements to control this behavior. Its value must be yes or no. If set to yes, the undefined data is treated as non-matched and the matching continues to other elements. The default is no (trying to match undefined data results in termination of the connection).

For example, encountering the following selector causes the connection attempt to end in failure if the certificate is not available or does not contain the altname-email field:

<selector>
  <certificate 
   field="altname-email" 
   pattern="%username%@ssh.com" />
</selector>

The following selector simply does not match when the certificate does not exist or does not contain the altname-email field, and the processing continues with the next block:

<selector>
  <certificate 
   field="altname-email" 
   pattern="%username%@ssh.com" 
   allow-undefined="yes" />
</selector>