1. UNIFYBroker Forum
  2. Questions
0
Answered

Can Identity Broker schema validation errors be better handled?

Matthew Clark 13 years ago • updated by anonymous 9 years ago • 5

We recently encountered an issue where a significantly large connector import contained a user with some bad data which mismatched its expected schema type (Identity Broker schema expected an integer, where the target system fed in the value "1.00E+01"). This is obviously quite frustrating, especially if this could happen at the end of a large import from a critical system, where large amounts of changes are expected. This is the behaviour of most of our current connectors (if not all, eg. Chris21, SharePoint).

An alternative considered was to individually log the entities which contain bad data, and continue the import. However, this has further reaching implications:

  • If the Identity Broker logs are not routinely monitored, entities containing bad data could be completely ignored in the solution
  • If a user is provisioned through the identity management solution, and at a later stage has bad data introduced, the user could be removed by a connector full import, and would then flow through as a delete through the solution

Identity Broker currently does not have a "strong" mechanism for informing users of events such as these outside of its current behaviour of halting the entire import. An alerting system similar to Event Broker 3 could prove useful, but still faces the dilemma of being ignored if not routinely monitored.

Can we make any improvements to address this issue?

Matthew Clark 13 years ago

This issue also relates to IDB-124 and any behaviour pertaining to a full import operation on a connector or an adapter. In the case of IDB-124, throwing an error for each distinguished name would invalidate the entire import. Throwing an error at the end of the import once all containers are present would give the right result, but could potentially mean much wasted time waiting for the entire import to complete. The alternative of simply logging the duplicate containers could result in similar problems to the above.

Possible methods for addressing the issue:

  • Let it persist given the negative ramifications of the alternatives.
  • Enabling email/SCOM notifications which may be a bit stronger.
  • Allow Identity Broker to log errors as it goes in a similar fashion to FIM - point-in-time errors containing specific data about failed users as they occur, rather than leaving this entirely up to checking the log file (ie. an Identity Broker "run history").
Adam van Vliet 13 years ago

Matthew,

Let it persist given the negative ramifications of the alternatives.

This is not possible, considering the problem is due to either bad data; or due to misconfigured solution. Both of these schenarios must be fixed up before continuing, to avoid an inconsistent solution.

Enabling email/SCOM notifications which may be a bit stronger.

Email notifications are already part of IdB. SCOM notification are already something we are interested in doing.

Allow Identity Broker to log errors as it goes in a similar fashion to FIM - point-in-time errors containing specific data about failed users as they occur, rather than leaving this entirely up to checking the log file (ie. an Identity Broker "run history").

This is not possible due to limitation in FIM, not allowing for partial imports. It is also a bad idea, due to IdB claiming to expose the full data set.

Peter Wass 13 years ago

Guys
Thoughts from the field:
Logging the errors to the event log will allow monitoring much the same as they can be monitored for FIM.
If the record fails data validation but already exists, can we leave the record unchanged. I'd be fine with that being implemented, especially if an alert was triggered in some fashion for notifications.
We currently log errors on import for individual objects in the Aurion connector. Something like this would work...

Matthew Clark 13 years ago

I believe since this issue has been open we have had a number of discussions where we have said the alternative of mismatching data is far worse than the "one fails all fail" approach.

Marked as resolved, please confirm if appropriate.

Matthew Clark 13 years ago

Closed - see IDB-302.

Customer support service by UserEcho