0
Fixed

Support date format in LDIF that is recognised by FIM Portal

Shane Day (Chief Technology Officer) 8 years ago in UNIFYBroker/Microsoft Identity Manager • updated by anonymous 3 years ago 7

When exporting a date field (such as EmployeeStart) to the FIM portal, if this field has been supplied by a date field in Identity Broker, a datetime-string-format-incorrect error occurs.

The work around is to use a concatenation of T00:00:00.000 on the end of the date value.

As in improvement, Identity Broker should supply this field in a format that FIM recognizes.

Affected Versions:
Fixed by Version:

If the problem is specific to FIM and we're already doing the correct thing based on the LDIF specification, please ensure that any changes only affect FIM and not other systems.

Shane,

This is a well-known issue with the FIM Portal, affecting all connected systems using a value other than the above highly specific format. See http://granfeldt.blogspot.com/2010/03/exporting-employeestartdate-to-fim-2010.html, http://www.identitychaos.com/2010/01/fim-2010-contributing-datetime-values.html, and various Technet forum posts. This restriction not only affects our ISO8601 compliant complete date format currently used, but also the timestamp format (FIM Portal does not support the Zulu ("Z") specification).

A fully compliant LDAP server would represent both date and timestamp formats using the Generalized Time definition defined in RFC4517, of the format:

199412161032Z (UTC)
199412160532-0500 (Offset for timezone)

This change to the date format would affect a number of our solutions that are already deployed, and is only a requirement of the FIM Portal (which requires similar processing for all fields from all target systems of this nature). It has the potential to introduce additional overhead to existing solutions that do not utilize a date type in this format. As such, I believe this processing should occur at the solution level (as it already does in a number of implementations, using a simple DateTimeFormat function, and/or a CustomExpression in one of our environments). Of course, our documentation should include this information. If this is a necessary requirement, some alternatives could involve:

  • A new date validator type that formats the value in this manner
  • A transformation that parses a date into a required format

Please confirm a solution you believe to be appropriate.

Date values when using the FIM compliant endpoint will now be outputted in the format required by FIM Portal:

yyyy-MM-ddTHH:mm:ss.fff

This has been unit tested. Please confirm resolution.

This is a feature for a future version of Identity Broker. If you require a date value in the format that FIM Portal supports for current versions you will need your solution logic to convert it appropriately.

Multiple endpoints covered by 3.2.9 of regression test document.