Client Identification Methods

Rule matching is based on the client identity and the client request.

There are two client identification methods:

X.509 Certificate Authentication
Client IP Address Identification

X.509 Certificate Authentication

X.509 certificates identify an entity. An entity can be a program, person, or host computer. When an X.509 certificate is authenticated, it authenticates that the entity is who it claims to be.

X.509 certificates are utilized in UACL entries by first mapping a client certificate to a UACL certificate identifier. The certificate identifier then is used in the UACL entries. A certificate identifier provides for:

Concise representation of certificates in UACL entries. There are a large number of certificate fields that may be used and many of the fields have lengthy, tedious naming formats. A certificate map only needs to be defined once and then the concise certificate identifier can be used in the UACL entries.
Mapping of one or more certificates to a single certificate identity. A group of entities that share a common security access level may be represented by one certificate identity reducing the number of UACL entries to maintain.

UACL certificate map entries are searched sequentially (that is, top to bottom) matching the client certificate to each entry until a match is found. The certificate map defines a set of X.509 certificate fields that may be used as matching criteria.

Certificate Map Matching Criteria

The following table defines the certificate map matching criteria.

Criteria	Description
SUBJECT	Matches the X.509 subject field. The subject field is formatted as an X.501 Distinguished Name (DN). A DN is a hierarchical list of attributes referred to as Relative Distinguished Names (RDNs). RDNs are separated with a comma ( , ) by default. If a different separator is required (perhaps one of the RDN values uses a comma), start the DN with the different separator character. Valid separators are slash ( / ), comma ( , ), semicolon ( ; ), and period ( . ). Many RDN values can be used in a DN. Some of the most common values are: C (Country name) CN (Common name) L (Locality) O (Organization) OU (Organizational Unit) ST (State) The RDN attributes must be listed in the same order as they are defined in the certificate to be considered matched. A partial DN can be specified. All certificates that have a subject name that matches up to the last RDN are considered a match. This permits a group of certificates to be matched. The RDN attribute values can include pattern matching characters. An asterisk ( * ) matches 0 or more characters and a question mark ( ? ) matches one character. Some example of SUBJECT values are: subject="C=US,ST=Georgia,O=Acme,CN=Road Runner" *subject="C=US,ST=Georgia,O=Acme,CN=Road \ " subject="C=US,ST=Georgia,O=Acme,CN=Road ?unner"** Whether or not an RDN value is case sensitive depends on the format in which the value is stored. The certificate creator has some control over which format is used. All formats except for printableString are case sensitive.
EMAIL	Matches the X.509 emailAddress attribute of the subject field and rfc822Name of the subjectAltName extension value. Both fields format the email address as an RFC 822 addr-spec in the form of identifier@domain. The attribute values may include pattern matching characters. An asterisk ( * ) matches 0 or more characters and a question mark ( ? ) matches one character. Some example EMAIL values are: email=user1@acme.com *email=\@acme.com email=user?@acme.com** RFC 822 names are not case sensitive.
HOSTNAME	Matches the following X.509 fields in the order listed: dNSName of the subjectAltName extension value. commonName (CN) RDN attribute of the subject field's DN value. Some example HOSTNAME values are: hostname=bigfish.acme.com *hostname=.acme.com** The values are not case sensitive.
IPADDRESS	Matches the X.509 iPAddress field of the subjectAltName extension value. An example IPADDRESS value is: ipaddress=10.20.30.40
SERIALNUMBER	Matches the X.509 serialNumber value. The value can be specified in a hexadecimal format by prefixing the value with 0x or 0X, otherwise, the value is considered a decimal format. For example, the value 0x016A392E7F would be considered a hexadecimal format. An example SERIALNUMBER value is: serialnumber=0x7a2d52cbae

Certificate Identifier Field

If a certificate map rule is found that matches the client certificate, the rule's identifier is assigned to the client's request. The certificate identifier is then used in matching certificate-based UACL entries.

The following table defines the certificate identifier field as used in UACL entries.

Field

Description

CERTID

Matches the certificate identifier defined by the certificate map entry. The CERTID value has the following syntax:

An asterisk ( * ) matches 0 or more characters and a question mark ( ? ) matches one character. For example, AB*M matches ABCDM and ABM. AB?M matches ABCM, but not ABCDM.
The comparison is case insensitive.
Pattern matching characters, such as the asterisk and question mark, are included in the text to be matched by prefixing them with a forward slash ( / ) character. For example, A/*B matches A*B. A//B matches A/B.

Client IP Address Identification

TCP/IP provides a method to obtain a client's IP address. The IP address typically identifies the host computer on which the client is executing. However, there are exceptions to this. Networks can be configured with Network Address Translation (NAT) systems between the client and the Broker that hides the client's IP address. In addition to the client IP address, Universal Agent clients provide a user account name with which they are executing that is used to further refine the client's identity.

UACL entries are searched matching the client's IP address and user account to each entry until a match is found.

Client IP Address - Matching Criteria

The following table defines possible matching criteria for IP address and user account client identification.

Field

Description

HOST

Matches the TCP/IP address of the remote user.

The HOST value has the following syntax:

Dotted numeric form of an IP address. For example, 10.20.30.40.
Dotted numeric prefix of the IP addresses. For example, 10.20.30. matches all IP addresses starting with 10.20.30. The last dot (.) is required.
A net/mask expression. For example, 131.155.72.0/255.255.254.0 matches IP address range 131.155.72.0 through 131.155.73.255. The mask and the host value are AND'ed together. The result must match net.

Note

Contact your network administrator for calculation of the correct net / mask expression.
Host name for an IP address. For example, sysa.abc.com.
Host name suffix for a range of IP addresses. For example, .abc.com matches all host names ending with abc.com, such as, sysa.abc.com. The first dot (.) is required.
An alias of a defined host. The application recognizes values prefixed with the @ symbol as a possible alias to the actual host name of a client. For example, an entry of @sysa.xyz.com matches a client whose actual host name is sysa.abc.com, provided that sysa.xyz.com is a defined alias of that host. Note that the entry is also considered a match if sysa.xyz.com is the actual host name of the client.
A value of ALL matches all IP addresses. The value must be uppercase.

REMOTE_USER

Matches the user name with which the remote user is executing as on the remote system.

The REMOTE_USER value has the following syntax:

An asterisk (*) matches 0 or more characters and a question mark ( ? ) matches one character. For example, AB*M matches ABCDM and ABM. AB?M matches ABCM but not ABCDM.
Control code /c switches off case-sensitivity and /C switches on case?sensitivity matching. The default is on. For example, /cABC matches abc. /ca/Cbc matches Abc but not ABC.
Pattern matching characters, such as the asterisk and question mark, are included in the text to be matched by prefixing them with a forward slash ( / ) character. For example, A/*B matches A*B. A//B matches A/B.