0

Identity Broker – the identity bridge for the new hybrid cloud enterprise

Share this content:
LinkedIn
Facebook
RSS

The Cloud is here to stay, and enterprises are migrating as much as possible to it at a rapid rate. KuppingerCole claim that “Security is a risk and an opportunity” in the Age of Transformation, and it is clear that as the distribution of workloads and data changes, the nature of data security changes. Gone are the days where everything sits behind a corporate firewall and there are internal teams looking after system security.

There are long check lists used by all natures of organisations assessing the risks of cloud service providers and whether it is appropriate for consumption. Government agencies (such as New Zealand Government) focus on items such as ISO 27001 compliance and data sovereignty. Most worry about ownership of data and the anti-intrusion capabilities of the system.

Identity integration can be a bit of an after thought. After all, cloud services are great for line-of-business applications – standing up new services quickly without needing anything other than a credit card and a decent Internet connection means you don’t have to go through all of those pesky capacity, disaster recovery and support planning scenarios. For ubiquitous enterprise services such as collaboration and office productivity, unless you had very strict security requirements, you’d be mad not to use a service like Microsoft Office 365 or Google for Business. Who wants to employ Exchange administrators on a 24-hour roster, right?

New businesses, or those nimble enough, can even plan their business to have very little on premises infrastructure at all. Here at UNIFY, we have rapidly removed the need for on-site infrastructure, our directory is based on a pure cloud Azure Active Directory and all new applications integrate with this.

This is all great – good Cloud based services use well known security protocols – SAML 2.0 is well adopted and OAUTH2/OpenID Connect patterns are increasing in adoption across the industry, particularly as certification for OpenID Connect was announced in 2015. At UNIFY, we have even taken to advising our valued customers to change ICT procurement procedures to include these abilities as a “must have” in evaluation score cards.

However, not every ICT workload is well suited to cloud computing. Some systems have specialist requirements, such as SCADA systems that have physical network requirements, or are legacy systems that are difficult to move and are not designed for use with loosely coupled identity protocols.

As Identity is the New Perimeter (Gartner) and the pace of change increases, the ability to connect these systems into both traditional Identity Management and new, lightweight Identity-as-a-Service systems such as PingOne or Azure Active Directory is just as important as ever.

UNIFY’s Identity Broker was traditionally built for on premises identity solutions, however since the release of v5.0, it is increasingly capable of being used as an Identity Bridge between traditional and Cloud-based identity services. The main use cases addressed are:

  • Protocol translation – the efficient modelling engine allows the mapping of relational data present in systems to the schemas required for LDAP/LDIF or SCIM, and the connectivity framework allows easy interaction with the target system, no matter how the integration service contract operates. There is no “Web Service Connector” that assumes a particular service contract or protocol, this is all under the complete control of the developer using C# or PowerShell, and with an extensive set of libraries.
Identity Broker includes an efficient data modelling engine, allowing the translation of relational-style data to heirarchical identity schemas.

Identity Broker modelling engine

  • Black boxing – Line-of-business system developers are often not identity experts, even though they deal with identity data. We use Identity Broker as a “Black Box” to provide identity interaction with industry standard protocols. This results in repeatable solutions for customers of application vendors – this has been well proven with our partners Aurion Corporation and Frontier Software. As these vendors move towards Cloud-based delivery of their own products, the architecture of Identity Broker provides an ideal way to provide white-label Identity Management components for their customers.
Identity Broker was traditionally used for black-box integration of on premises systems, typically HR. The architecture allows for this same functionality to be provided as white-label services in the Cloud.

Traditional Use for Identity Broker

  • Light-weight synchronization – the bulk of Identity-as-a-Service offerings are about leveraging existing directory infrastructure. As this results in identity information being proliferated around the internet, it is more important than ever that the information in these directories is correct. The Identity Broker LITE technology allows light-weight on premises or cloud based delivery through UNIFY’s Identity-as-a-Service solution.
Identity Broker LITE synchronisation engine provides light-weight identity synchronisation suitable for on-premises or Cloud delivery. It forms the basis of UNIFY's Identity-as-a-Service offerings.

Identity Broker LITE synchronisation engine

  • Multi-targeting identity information – large enterprises have many identity systems in place; often multiple provisioning platforms, attestation solutions, role mining engines. Identity Broker’s LDAP engine allows consumption of this identity data by many sources without further development.

 

Identity Bridges are emerging in importance as enterprises incorporate more Cloud Computing. KuppingerCole have already looked at Identity Broker as a way to implement a bridge to get the best out of both worlds. Any of our identity evangelists or architects at UNIFY are able to demonstrate how Identity Broker enables the best of on premises and Cloud for you Identity Solution. To learn more, please contact us.

Shane Day

Leave a Reply

Your email address will not be published. Required fields are marked *