Identity Broker support for consolidating multiple instances of same connected system

This issue has not been updated in 2 weeks. Please provide a status update or progress the issue appropriately.

Marked as resolved due to present obvious lack of interest from UNIFY in this idea. Can be reopened if this position changes.

I am just reviewing a requirement CSODBB-238 whereby the HR system (ConnX) also supports multiple database instances for the same organisation. While SAS is being consolidated at "some future stage" by CSODBB, at this point the CSODBB service desk is reduced to manually running a "SAS2IDM" custom merge application twice a day, and then manually running FIM imports ... defeating the purpose of Identity Broker really. Still, it looks like there are a number of other potential uses for this idea apart from ConnX (I am hoping they only turn out to have the one instance) - Ryan Crossingham is looking at an Aurion problem for Salmat with a variation on this requirement right now.

Salmat are looking at a 3rd Aurion instance. This would certainly help their situation (soon to be mine)..
Bob - Who looked into this and called it as unfeasible?

From memory I was talking to Shane Day about this but it could have been Adam van Vliet too. My thinking was that it would be nice to have multiple connection nodes and for each to aggregate for the same connector, but the fear I think was that this would undermine some core Identity Broker principles?

Adam van Vliet - rather than complicating the adapter design I was thinking more of a generic connector feature to "union" multiple connector sources with the exact same connector schema but unique ranges of key properties (thereby ensuring uniqueness). Generally speaking this could be potentially achieved by supporting multiple communicator nodes for the same connector. If not, then at least multiple dataConnection nodes for the same communicator node. In other words, this is hidden from the adapter and the connector does the mapping work under these very strict constraints. The connector would have to recognise there are multiple sources and treat them as a collection of sources to be iterated through in order to perform a full or delta import. I imagine export could be harder to handle, but with an extra piece of data for each connector object identifying the ID of the communicator/dataConnection then this could be achieved?

The choice between connector and adapter isn't what makes this difficult. With only this in mind the adapter would actually be better suited, as it already performs this 'type' of work.

Happy to discuss further on a feature request.

Created new IdB feature request PRODUCT-306 as requested by Adam van Vliet, also on behalf of Ryan Crossingham who is facing the same requirement now at Salmat.

From https://unifysolutions.jira.com/browse/IDB-1111:

The requirement is to be able to cater for applications such as HR systems which support multiple instances of their application whereby the data can be consolidated such that each identity is unique not only across the application instance, but across all instances in the same pool. In each case the schema is identical for each instance, and only the instance ID varies from instance to instance.

An example of this is the SAS application at CSODBB, whereby a custom middleware application had to be written in house (SAS2IDM) in order to amalgamate identity data from all instances in order to support a single Identity Broker configuration (SQL connector to a SQL view), and through to a single adapter. A feature such as the one I am looking for would eliminate the need for any such middleware, thereby improving usability and reliability (the current SAS2IDM implementation was an application not a service, and as such has to be initiated manually twice a day by the CSODBB service desk).

In discussions with Adam van Vliet there are two approaches that might be taken:

1. adapter feature to "union" multiple connectors with identical schema (Adam's preference as being most consistent with the architecture)
2. connector feature to allow for a collection of communicator or dataConnection nodes (Bob Bradley suggestion not preferred by Adam)

My thinking around option #2 above was that it would be the simplest from an implementer's perspective (i.e. no duplication of the same connector definition - in the SAS2IDM case this would be 44 almost identical connector definitions). This would lead to consistency problems where changes would need to be replicated 43 times.

Either way, such a feature would allow us to implement a single FIM management agent across all instances without the need for custom middleware or the need for multiple management agents (both of which reduce the value proposition for Identity Broker). Multiple management agents is a problem from both a maintainability perspective in the same way (but far worse) that it is for multiple connectors. It would also add significant operational and performance overhead.

From https://unifysolutions.jira.com/browse/PRODUCT-397:

Thought this was worth explaining another way, having seen how Optimal's VIS product achieves the same outcome.

In the VIS product I can create multiple AD VISAs (think IdB connectors), and by default these are merged into an aggregate "view" (hierarchy) as follows:

• OU=VIS
  • OU=AD1
    • OU=Users
    • OU=Computers
    • ...
  • OU=AD2
    • OU=Users
    • OU=Computers
    • ...
  • ...

Since the DN is guaranteed unique within each AD forest, it follows that the aggregated VIS DN is also guaranteed unique under this umbrella hierarchy model. It would also follow that domain.sAMAccountName would also be an alternative unique key. This is the default VIS model ... but VIS also supports joins whereby connector attributes are merged when joins are established on common keys.

This is basically what I was looking for with CSODBB-173 originally - something that may be a whole lot easier to implement in IdB5's new LDAP adapter model.

At CSODBB the requirement would be to incorporate 44 schools in a DN hierarchy under OU=SchoolID, and have 44 instances of effectively the same connector with a different school connection. So while IdB's default model is to JOIN connectors, a secondary option to UNION these instead would provide the outcome necessary to meet the SAS requirement. As it turns out SAS is now about to be replaced with a different hosted school system (not sure what yet) and depending on the partition model this may or may not be a requirement any more.

At QBE we have about a dozen AD forests in the Latin Americas (LatAm region) that need to be incorporated into the FIM solution. I have suggested that rather than implement a FIM management agent (MA) for each forest (as is the extensibilty model so far), we could instead implement a single LatAm MA by using VIS to combine (union) all these forests into a single (virtual) directory. Unlike with IdB, the existing AD MA can be used, since VIS can emulate AD (complete with DirSync searches and Kerberos auth). For this idea to benefit QBE, not only would IdB also have to emulate AD, but it would need to support the UNION model.

The above 2 examples now represent a recurring requirement worthy of reconsideration - and it may (or may not) turn out that we will actually need this for the new CSODBB student system (some time in 2016).

Not enough value in request.