What is Identity Broker?

To paraphrase an earlier post, FIM Sync would be easy if every system or application was as straight-forward to provision and sync with as the AD or ADLDS connector. It struck me sitting in Chris Cox’s FIM 2010 RC0 training back in January 2009 that with all the attention now on FIM policy and workflow, and all things to PowerShell, it was almost as though there was a blind assumption that this was actually the case. This also seemed to be the assumption during an Omada 6.1 training course in June 2008. The fact that systems such as HR, telephony, ERP and bespoke applications we all need to leverage as sources of truth for identity are anything but that simple was seemingly trivialised. Now we have ECMA2 and it’s even easier than before, right? Well think again. Think about any instance of the AD connector and what FIM Sync features we take for granted here:

  • LDAP API
  • Delta imports
  • Multi-value attributes
  • Multiple object classes
  • Bi-directional attribute flows
  • Change events

Now think about connecting to just about any commercial HR system – e.g. in Australia we have chris21, Aurion HR, SAP, Talent2, Empower HR, Peoplesoft HR … the list goes on. Some of them have APIs and some don’t, but apart from that can you imagine how you would go about building a custom connector to any of these with one or two let alone ALL of the above features? Add to that the fact that most of the data you need to present in a consolidated Person object is invariably stored in at least half a dozen separate but related data stores, and you quickly find you’re compromising performance and usability in order to bring all this information together. After a short while you pretty much find yourself trying to sync apples with oranges … This is why UNIFY’s Identity Broker 4.0 connector platform is a game changer. You could think of it as an proxy LDAP API for application XYZ. Any application or service where there is an Identity Broker Connector for Application XYZ will provide ALL of the above features and some (such as derived attributes and transformations in the connector layer). Now you can sync apples with apples 🙂 … and scale to the millions of apples for good measure. This is not so much a plug for some fantastic technology, but an attempt to dispel some of the confusion and misinformation I’m hearing from people in the market about what Identity Broker is about – not to be confused with FIM Event Broker which by the way leverages any such connector to deliver real time sync too. So today any FIM 2010 training course which continues to sets the same expectation it seemed to in 2009 sits comfortably with me, knowing that this can now be the case. We should all rejoice that more people can take a dip in the FIM pool for themselves (i.e. more CAL sales!) without running into the brick walls of the past. There – I got that off my chest!

Advertisement

About bobbradley1967

Microsoft Identity and Access Professional with 2 decades of successful IAM implementations in APAC, specialising in MIM and its predecessors (FIM/ILM/MIIS) and now with SoftwareIDM. A Microsoft IAM MVP prior to that with a background in MS.Net applications development/SI. Now with a particular interest how Identity and HyperSync Panel provide the Identity and Access orchestration presently missing in the Azure Entra Suite to effectively enforce Zero Trust on the M365 platform.
This entry was posted in Event Broker for FIM 2010, FIM (ForeFront Identity Manager) 2010, ILM (Identity Lifecycle Manager) 2007 and tagged , , , . Bookmark the permalink.

Leave a Reply

Please log in using one of these methods to post your comment:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.