- UNIFYBroker Forum
-
Ideas
Is there an Identity Broker 3.* transformation that will union multiple connectors with the same schema into a single adapter?
CSO have deployed an Identity Broker for SAS2IDM, which is a custom application (apparently written in-house by CSO?) which does nothing more than consolidate data from 43 school "SAS2000" instances of the same remote SQL database table into a consolidated single database (not sure but I think to separate tables within the same db) ... and at the same time constructing a unique key (school ID concatenated to student ID). This is achieved using a monolithic database view (suspect this is a SQL union).
Given that this tool was built (it seems) prior to UNIFY's engagement (some time after March 2011) to build the Identity Broker for SAS2IDM (CA November 2011 - although Shane Lim may have built an earlier version which wasn't used), there appears to be no discussion about how Identity Broker might be used to access each SAS2000 database using 43 separate instances of the same connector schema, and combine them into a single adapter, thereby making the SAS2IDM application redundant. This would be a good thing as it would dramatically simplify the architecture.
The question is this ...
Can such an adapter be built now using the latest 3.0.7 version of the Identity Broker software, using an adapter configuration something like the following:
compositeAdapterConfiguration> <AdapterEngineCOnfigurations> <Adapter Configuration BaseConnectorID="1" class="person /> <Adapter Configuration BaseConnectorID="2" class="person /> <Adapter Configuration BaseConnectorID="3" class="person /> ...
or would a new transformation(s) need to be developed to support this?
Given that I can think of 2 sites where this requirement would have been considered too (News Ltd before they consolidated on a single HR instance, and an ACT education site somewhere), I expect this concept is not new.
To explain the architectural reason for consolidating 43 connectors into a single adapter like this is so that we have a single FIM MA with a single CS/MV/Portal object, currently managed by 10+10+10 FIM policy objects. If we tried to suggest 43 management agents here, that totally wouldn't fly (43x30=1290 FIM policy objects and a maintenance nightmare).
Customer support service by UserEcho
As per the discussion between myself and Bob, regarding News Ltd I believe the scenario was slightly different as users could exist in multiple of the connected systems, where my understanding for CSO DBB is that each schools set of users is mutually exclusive from one another.
News was achieved by having N number of connectors and N number of adapters for N number of systems, with each joining to a single metaverse object in FIM with the codeless framework determining whether attributes should flow based on extension rules.
CSO seems to be a union of the results where based on what I understand, each identity exists in only one school and thus a union of the records is possible (I have no info on how the data looks if a student changes enrolment, whether the identity follows them or what).
Hi Bob,
No, not for version 3. It is something we will consider looking at in the future, but I don't know when.
Thanks for the clarification Adam ... apparently there are political (security restrictions I don't have any background on) and volatility issues at this site whereby the SAS2IDM solution is effectively acting as a (crude) API for us to access SAS2000. Hence we have to live with the status quo ... including the fact that SAS2IDM doesn't run as a Windows service and so there has to be an active logged on session at all times (a worse security hole than I imagine would be posed by using Identity Broker connectors, and running the Identity Broker service in the same security context as SAS2IDM itself!!!).
I will also add that it is technically impossible for a transformation to achieve the union of multiple connectors. Transformations can only operate on data from the base connector.
OK - I can take your word for that, but that doesn't detract from the value proposition of being able to do just this, given that we're up to the 3rd known potential use of it. We probably just need to brainstorm this a bit for the next version ... I appreciate there must be rules in place which govern what can and can't be done with IdB 3 or earlier, but I don't see why we're not collectively bright enough to come up with an answer to this that gives the desired outcome (single consolidated MA with an aggregated CS object). I can think of a myriad of decentralised scenarios where this would make an otherwise unmanageable ILM/FIM sync server configuration totally manageable all of a sudden (branches/agencies in organisations like banks, schools in clusters, HR systems across global locations, ...)
P.S. "the base connector" ... that is what we're really asking ... is it beyond the realms of possibility to have multiple base connectors?
Yes, it is impossible in the life-cycle of v3 to have multiple base connectors for an adapter. It would be a major architectural change.
For re-consideration with version 4.* - feature request?