Identity Broker for Microsoft Identity Manager Attribute Types and Reference Attributes

Type Mapping

Identity Broker's expansive schema allows for the definition of a flexible set of attributes in the FIM management agent. Below is a table showing the mapping of Identity Broker types to FIM types.

Identity Broker Type FIM Type

Date

Decimal

Double

Guid

Single

String

Time

Timestamp

String

Byte

Integer

Long

Short

Number
Binary Binary
Boolean Boolean
DN Reference

Depending on the expectations of the target system, Guid may also be mapped to a binary.

Identity Broker may also convert string attributes in FIM to most types, including reference attributes. This may be used to emulate referencing and memberships without requiring the object to exist in the connector space as is usually required.

INFO: The Identity Broker types Date and Timestamp send over LDAP in  Generalized Time format.

Considerations for Reference Attributes

Implementers need to be wary of the use of and changes to the distinguished names of objects. The following should be considered:

  • Introducing a container that contains different casing to objects already existing in the connector space can result in large amounts of recalculation on the Referential Updates step of a sync, and can produce undesirable results.
  • For a reference attribute to correctly resolve in the metaverse, the object must exist with the referenced DN in the same management agent as it is first referred to. In other words, if  CN=101 has a manager  CN=102 and an entitlement  CN=HRAccess101,CN=Entitlement, both the manager and the entitlement object must exist in the connector space for the reference to resolve
  • In some systems, employees in the highest location in the hierarchy will contain a reference to themselves (ie. they are marked in HR as being their own manager). This should be kept in mind if advanced synchronization logic is attempting to determine or use hierarchy.

Self-Referencing Issue

In situations where a management agent is required to export entities which contain references to other entities within the same space, issues may arise. This is due to how FIM calculates reference values on multiple passes. The first pass sends a request to create the entity in the Identity Broker adpater, then the second pass sends an update request adding the resolved reference DN to the entity. If the DN attribute in Identity Broker is flagged as  Required then the initial add requests without the required field will fail. If not required, the second pass update request will fail as not enough time has passed for the newly created entity to be reflected to the adapter.

The current workaround for this issue is to ensure that the self-referencing DN attributes are not flagged as  Required and to run the FIM Export operation a second time after a short window.

Implementers need to be wary of the use of and changes to the distinguished names of objects. The following should be considered:

  • Introducing a container that contains different casing to objects already existing in the connector space can result in large amounts of recalculation on the Referential Updates step of a sync, and can produce undesirable results.
  • For a reference attribute to correctly resolve in the metaverse, the object must exist with the referenced DN in the same management agent as it is first referred to. In other words, if  CN=101 has a manager  CN=102 and an entitlement  CN=HRAccess101,CN=Entitlement, both the manager and the entitlement object must exist in the connector space for the reference to resolve
  • FIM calculates reference values on multiple passes, and requires the target object to exist in the space it is passing the value to. While this appears to succeed when viewing the user in the connector space, at times it does not correctly resolve self-references when exporting entities. This results in an object being passed to Identity Broker with the reference field empty. This issue is best resolved by  dereferencing the source attribute. This is as simple as opening the management agent in question, browsing to the  Configure Attributes tab, and changing the attribute from a  Reference type to a  string type. This forces FIM to correctly calculate the reference, while the reference will still be correctly resolved in Identity Broker and the target system.
  • In some systems, employees in the highest location in the hierarchy will contain a reference to themselves (ie. they are marked in HR as being their own manager). This should be kept in mind if advanced synchronization logic is attempting to determine or use hierarchy.

Multivalue Attributes

Version 5.0+

Identity Broker multivalue attribute types can be directly mapped to FIM attribute types with two exceptions:

  1. Identity Broker supports multivalue boolean attributes, however FIM does not.
  2. FIM supports multivalue binary attributes, however Identity Broker does not.


Is this article helpful for you?