Restricting access through client connection policies
Whenever a client establishes a connection to the PingDirectory server, that connection is associated with a client connection policy, which can restrict the kinds of requests that the client can issue and impose resource limits for that connection.
The server uses the following properties to determine which client connection policy should be associated with a client connection:
evaluation-order-index
-
An integer value that specifies the order in which the client connection policy will be evaluated relative to other policies. Each client connection policy must have a unique evaluation-order-index value.
connection-criteria
-
An optional set of criteria that indicates which connections are allowed to be associated with the client connection policy. That criteria can take several things into account, including the address of the client, the connection handler that accepted the connection, whether it is communicating with the server over a secure connection, whether the client is authenticated, the authentication mechanism, the location or content of the authenticated user’s entry, the groups in which that user is a member, and the set of privileges that they have. If the client connection policy is not associated with any connection criteria, then it matches any connection. See the Connection criteria section of this document for more information.
terminate-connection
-
A Boolean value that indicates whether to terminate any client connection in which the client connection policy is the first one to match the client connection.
Whenever the server accepts a connection, it iterates through all enabled client connection policies in order from lowest evaluation-order-index
value to highest. The first policy that the server encounters that either does not have connection criteria or that has connection criteria that matches the client connection is assigned to that connection. If the connection cannot be associated with any client connection policy because all enabled policies have criteria that do not match the client connection, or if the first matching policy has a terminate-connection
value of true, then the connection is terminated.
After processing each bind operation (which might change the authentication state for the client connection) as well as after each StartTLS extended operation (which might change the communication security for the connection) the server re-selects the client connection policy to use for that connection. It might assign the same policy or a different policy to that connection, or it might terminate the connection.
Client connection policy restrictions
Client connection policies can be used to set hard limits on what types of requests clients are allowed to issue.
This applies to all clients associated with the policy, regardless of what privileges they have and what access control rights they have been granted. If a client connection policy prohibits something, then not even root users or topology administrators are permitted to do it if they are using a connection associated with that policy.
The following client connection properties can be used to restrict the set of requests that clients can issue.
Property | Description | ||
---|---|---|---|
|
The types of operations that clients associated with the policy are allowed to request. Allowed values include any non-empty combination of the following: |
||
|
A set of criteria that requests must match in order to be processed by the server. If required operation request criteria is defined and a client associated with the policy issues a request that does not match that criteria, then the operation is rejected. By default, no required operation request criteria are defined. |
||
|
A set of criteria that requests must not match in order to be processed by the server. If a prohibited operation request criteria is defined and a client associated with the policy issues a request matching that criteria, then the operation is rejected. By default, no prohibited operation request criteria are defined. |
||
|
A set of criteria that requests must not match in order to be processed by the server. If a prohibited operation request criteria is defined and a client associated with the policy issues a request matching that criteria, then the operation is rejected. By default, no prohibited operation request criteria are defined. |
||
|
The OIDs of the controls that clients associated with the policy will be allowed to include in requests. If any allowed request control OIDs are defined, then any request that contains a control other than one of those listed is rejected. By default, no allowed request control OIDs are defined, which indicates that any control not included in the set of denied request controls is permitted. |
||
|
The OIDs of the controls that clients associated with the policy are not allowed to include in requests. If any denied request control OIDs are defined, then any request that contains a control whose OID is contained in this set IS rejected. By default, no denied request control OIDs are defined. |
||
|
The OIDs of the extended operations that clients are allowed to request. If any allowed extended operation OIDs are defined, then any extended request that uses an OID other than one of those listed is rejected. By default, no allowed extended operation OIDs are defined, which indicates that any request not included in the set of denied extended operations is permitted. |
||
|
The OIDs of the extended operations that clients are not allowed to request. If any denied extended operation OIDs are defined, then any request that contains a control whose OID is included in this set is rejected. By default, no denied extended operation OIDs are defined. |
||
|
The types of authentication that clients are allowed to request. Allowed values include |
||
|
The names of the SASL mechanisms that clients are allowed to use to authenticate. If any allowed SASL mechanism names are defined, then any SASL bind attempt that uses a mechanism not included in this list is rejected. By default, no allowed SASL mechanism names are defined, which indicates that any SASL mechanism not included in the set of denied mechanisms is permitted. |
||
|
The names of the SASL mechanisms that clients are not allowed to use to authenticate. If any denied SASL mechanism names are defined, then any SASL bind attempt that uses one of those mechanisms is rejected. By default, no denied SASL mechanism names are defined. |
||
|
The types of search filters that clients are allowed to use for searches with a scope other than baseObject (searches with a baseObject scope are allowed to use any kind of filter, as those searches are always be efficient to process). Allowed values include any non-empty combination of the following: |
||
|
The minimum number of consecutive non-wildcard bytes that must be present in each subInitial, subAny, and subFinal element of a substring filter component. Any attempt to use a substring filter with an element containing fewer than this number of non-wildcard bytes is rejected. By default, no minimum substring length is enforced. |
||
|
Indicates whether clients associated with the policy are allowed to request unindexed searches. If this is set to true (which is the default), then unindexed search operations are permitted in cases in which at least one of the following is true:
|
||
|
Indicates whether clients associated with the policy are allowed to request unindexed searches as long as the request also includes the permit unindexed search request control. If this is set to true (which is the default), then unindexed search operations are permitted in cases in which the requester has either the
|