Even though the PingDataSync server can perform its own attribute mapping on data read from the source server (as configured in the sync class), this isn’t sufficient on its own to interact with a SCIM 2.0 server.

In some cases, it might be necessary to transform values in a way that’s not easily accomplished with the existing attribute mapping mechanism that the PingDataSync server provides, for example, from a generalized time representation that is typically used for timestamps in LDAP entries to the ISO 8601 format described in RFC 3339 that SCIM 2.0 servers typically use.

The existing attribute mapping can also be inconvenient for generating SCIM 2.0 complex attributes.

Each SCIM 2.0 attribute mapping is associated with a syntax. The server supports the following types of SCIM 2.0 attribute mappings.

SCIM 2.0 attribute mappings Description

String

Used for SCIM 2.0 attributes represented as JSON strings. See String SCIM 2.0 attribute mappings.

Number

Used for SCIM 2.0 attributes represented as JSON numbers. See Number SCIM 2.0 attribute mappings.

Boolean

Used for SCIM 2.0 attributes represented as JSON Boolean values. See Boolean SCIM 2.0 attribute mappings.

DateTime

Used for SCIM 2.0 attributes in which the LDAP representation is a timestamp in the generalized time format, and the SCIM 2.0 representation uses the format described in RFC 3339. See DateTime SCIM 2.0 attribute mappings.

Postal Address

Used for SCIM 2.0 attributes in which the LDAP representation is a string that represents multiple lines using the dollar sign character ($) as the line delimiter, and the SCIM 2.0 representation uses newline characters (\n) to separate the lines. See Postal address SCIM 2.0 attribute mappings.

Composed Complex

Used for SCIM 2.0 complex attributes in which the sub-attributes are defined with other SCIM 2.0 attribute mappings. See Composed complex SCIM 2.0 attribute mappings

JSON-Formatted Complex

Used for SCIM 2.0 complex attributes in which the JSON objects that represent the complex attributes are read from a specified attribute in the mapped LDAP representation of the entry. See JSON-formatted complex SCIM 2.0 attribute mappings.

Each of these will be described in more detail in its own section, but all types of attribute mappings share the following configuration properties:

scim-attribute-name
The name of the attribute as it appears in SCIM 2.0 entries. This is required.
attribute-usage
The ways in which the associated attribute is used. It must have at least one of the following values:
  • fetch – The attribute is to be retrieved from the SCIM 2.0 server when fetching entries.
  • create-during-realtime-sync – The attribute is to be included when creating a new entry in the SCIM 2.0 server during real-time synchronization.
  • create-during-resync – The attribute is to be included when creating a new entry in the SCIM 2.0 server during resync processing.
  • update-during-realtime-sync – The attribute is to be updated if necessary when applying changes to existing entries in the SCIM 2.0 server during real-time synchronization.
  • update-during-resync – The attribute is to be updated if necessary when applying changes to existing entries in the SCIM 2.0 server during resync processing.
failed-mapping-behavior
Indicates how the PingDataSync server should handle cases in which an error occurs when trying to map a value between the LDAP and SCIM 2.0 representations of an entry, such as if the value doesn’t conform to the expected syntax. The value for this property can be one of the following:
  • reject – Indicates that the associated synchronization operation should be rejected. This is the default behavior that will be used if no value is specified.
  • ignore-entire-attribute – Indicates that the associated synchronization operation should proceed as if the entire attribute had been omitted, even if it’s a multivalued attribute in which other values can be successfully mapped.
  • ignore-individual-values – Indicates that the associated synchronization operation should proceed as if any unmappable values had been omitted. For single-valued attributes, or for multivalued attributes in which none of the values can be successfully mapped, this behavior will be the same as ignore-entire-attribute. For multivalued attributes in which at least one value can be successfully mapped, only the unmappable values will be omitted.
always-patch-with-replace
Indicates whether to always use the replace operation type when updating values of this attribute with a SCIM 2.0 PATCH operation (this property does not apply when replacing the entire entry with a PUT operation). By default, this property has a value of false, to indicate that it should attempt to update values for the attribute with the add and remove operation types when possible. However, for some types of attributes (for example, if the SCIM 2.0 server allows you to update passwords but not retrieve them, or if it only allows retrieving them in an encoded form that does not match the form in which it was obtained from the source server), it might be necessary to always use the replace operation type.

Just as it might be necessary to change the value of the always-patch-with-replace property when synchronizing passwords, you might also need to treat the attribute-usage property specially for passwords as well. This is especially true in cases where the clear-text password is available during real-time synchronization, but not during a resync.

This can occur, for example, when synchronizing from a PingDirectory server with the Changelog Password Encryption Plugin enabled because the plugin includes an encrypted representation of the clear-text password in the changelog record for operations in which a clear-text password was provided, but the clear-text password is not available during resync processing.

In such cases, you might need to omit the create-during-resync and update-during-resync behaviors if the SCIM 2.0 server cannot handle passwords in their encoded form.