For a PingDirectory server instance, data encryption only applies to the on-disk storage. Although it doesn't automatically protect information accessed or replicated between servers, the server offers mechanisms to provide that protection, such as SSL, StartTLS, and SASL.

All client communication using either SSL or StartTLS encryption and all replication traffic using SSL encryption helps ensure that the data is protected from unauthorized individuals who might eavesdrop on network communication. You can enable this communication security independently of data encryption.

Note:

If data encryption is enabled, you should use secure communication to protect network access to that data.

Protecting client data access isn't as simple as enabling secure communication. In some cases, you might want to allow insecure access to some data. In other cases, you might need to have additional levels of protection in place to ensure that some attributes are more carefully protected. To achieve varying levels of protection, use sensitive attribute definitions.

The following table explains the sensitive attribute definitions and their configuration properties.

Sensitive attribute Configuration details

attribute-type

Specifies the set of attribute types whose values might be considered sensitive.

You must provide at least one attribute type and define all specified attribute types in the server schema.

include-default-sensitive-operational-attributes

Indicates whether the set of sensitive attributes that might contain sensitive information should automatically be updated to include any operational attributes maintained by the PingDirectory server itself.

This includes the ds-sync-hist operation attribute, which is used for data required for replication conflict resolution and can contain values from other attributes in the entry.

allow-in-filter

Indicates whether sensitive attributes can be used in filters.

This applies not only to the filter used in search requests, but also to filters that can be used in other places, such as the assertion and join request controls.

The value of this property must be one of the following:

  • Allow: allows sensitive attributes to be used in filters over both secure and insecure connections.
  • Reject: rejects any request that includes a filter targeting one or more sensitive attributes over both secure and insecure connections.
  • Secure-only: allows sensitive attributesto be used in filters over secure connections but rejects any such requests over insecure connections.

allow-in-add

Indicates whether sensitive attributes can be included in entries created by ldapaddoperations.

The value of this property must be one of the following:

  • Allow: allows sensitive attributes included in add requests over both secure and insecure connections.
  • Reject: rejects any add request containing sensitive attributes over both secure and insecure connections.
  • Secure-only: allows sensitive attributes included in add requests received over secure connections but rejects any such requests over insecure connections.

allow-in-compare

Indicates whether sensitive attributes can be targeted by the assertion used in a compare operation.

The value of this property must be one of the following:

  • Allow: allows sensitive attributes to be targeted by requests over both secure and insecure connections.
  • Reject: rejects compare requests targeting a sensitive attribute over both secure and insecure connections.
  • Secure-only: allows compare requests targeting sensitive attributes over secure connections but rejects compare requests over insecure connections.

allow-in-modify

Indicates whether sensitive attributes can be updated using modify operations.

The value of this property must be one of following:

  • Allow: allows sensitive attributeto be modified by requests over both secure and insecure connections.
  • Reject: rejects any modify request updating a sensitive attribute over both secure and insecure connections.
  • Secure-only: allows only modify requests updating sensitive attributes over secure connections but rejects modify requests over insecure connections.
Note:

By default, allow-in-returned-entries, allow-in-filter, allow-in-add, allow-in-compare, and allow-in-modify properties have values of secure-only only. This prevents the possibility of exposing sensitive data in the clear to anyone able to observe network communication.

Sensitive attributes and client connection policies

If a client connection policy references a sensitive attribute definition, any restrictions imposed by that definition are enforced for clients associated with this client connection policy. If multiple sensitive attribute definitions are associated with a client connection policy, the server uses the most restrictive combination of all of those sets.

Sensitive attributes and other security mechanisms

The sensitive attribute definitions work in conjunction with other security mechanisms defined in the server and can only be used to enforce additional restrictions on clients.

Never use sensitive attribute definitions to grant a client additional access to information that it didn't have already through other means. For example, if the employeeSSN attribute is declared a sensitive attribute and the allow-in-returned-entries property has a value of Secure-only, then the employeeSSN attribute is only returned to those clients that have both permissions granted by the access control rules defined in the server and are communicating with the server over a secure connection.

The employeeSSN attribute is stripped out of entries returned to clients normally authorized to see it if they are using insecure connections. It is also stripped out of entries for clients normally not authorized to see it even if they have established secure connections.