John Jellema Catchy title, but where is this going? In the world of identity and access management, as Ubisecure we know we can help customers manage single sign-on(SSO) sessions no matter how complex their environment. It doesn’t matter if you have a dozen separate applications, each with their own local username and password, or if you have tens or hundreds of partners that you want to give secure, authenticated access to. We know we can help you. But we’re often asked, “how?”. Well, this is where SSO integration for the old, the new and the strange comes into play.
Our Identity Platform can integrate applications with both SAML and OIDC; each protocol has its own method to authenticate a user session. And we can create adaptors for nonstandard applications which integrate via a CIBA framework. But, SAML, OIDC and CIBA, how do I know if I use these already?
The Old
For those of you who know, SAML (Security Assertion Markup Language) uses a series of XML-based protocol messages to create user sessions. There is typically a human user, an identity provider (IdP) and a service provider (SP). That is – you on your web browser, a service that can identify you with authority and the place you are asking your web browser to log into. Keep in mind the IdP and the SP might look the same to you – but your browser knows the difference. Launched as 1.0 in 2001 and updated to 2.0 in 2005, SAML is the “grand old man” of authentication.
There are hundreds of thousands of applications, probably millions, which use SAML to securely authenticate users to services. SAML is tried, true and robust. If your company or partner has been offering services online since before 2010, then the SAML protocol is in use to authenticate users – human and machine. It’s no problem, Ubisecure Identity Platform supports SAML out of the box.
The New
OIDC or OpenID Connect. This is a decentralised authentication protocol which uses OAuth 2.0 as its authorisation framework. In brief, OIDC is a series of secure message exchanges that allow you to delegate access of your online content to a third-party resource or service. It’s the “give this app access to only these 10 pictures on my phone”.
Like SAML, OIDC also has a human user and identity provider (IdP). However, differs from SAML by using a relying party (RP) to securely control and limit the personal information or resources you are granting access to. This sounds a little complex but is really an elegant way for you to trust a known resource to control access to your information and only give out the specific information you want, when you want it. And revoke access when you want to; this is nearly as important as granting access. As OIDC was finalised in 2007, it’s not that much younger than SAML – but still the few years between the release of the two protocols makes OIDC the new kid on the block
If you use Facebook or Google, Twitter or hundreds of other applications or services, you have been using OIDC. Do you use your Office365 identity to log into your company’s ticketing or intranet site? That’s OIDC functioning to authenticate you, via Microsoft’s Azure Active Directory. It then creates an access token and id token to tell your company’s applications that you are a valid user and should be granted access.
The Strange
Ok – SAML and OIDC are pretty clear. They can both identify you as a user from a central location and exchange your right to access information from an online location. What happens when you discover that you have an application that is either COTS (commercial off the shelf) or homegrown that just doesn’t follow the standards? It’s an essential application, used for key business functions and it can’t be altered or rewritten quickly enough. This application needs to be available to your partners, but you don’t want the hassle of managing user accounts for all those external staff. Seems like a bind, but we have a solution here.
OIDC CIBA – OpenID Connect Client Initiated Backchannel Authentication, or just CIBA for short. Ubisecure’s Identity Platform has a CIBA framework that can help to integrate this non-standard (or strange) application. While this isn’t a plug and play solution, you or your System Integrator will need to work with our Sales Engineering team to identify your essential applications APIs, then integrate them into our CIBA adaptor. We will connect to your partner’s user directory via SAML or OIDC and to your key application via this CIBA adaptor.
In the modern reality, a diverse range of legacy and new applications coexist. Blending on-premises and cloud services is often the quickest way for any organisation to grow resulting in a hybrid IT environment. Of course, it’s better to follow open standards, either SAML or OIDC. But when your business requirements extend beyond the norm, by either the protocols used or into a hybrid deployment, come talk to us. We have long experience with SSO integration for complex environments, no matter if they are “old”, “new” or “strange”.
Contact us to speak with an IAM expert about your SSO integration requirements and to find out more.
About The Author: John Jellema
As VP Product Management, John is responsible for ensuring Ubisecure’s ongoing development of its Identity Platform, optimising the feature development while driving generational change across the IAM delivery platform. Since joining Ubisecure in 2017, John has refocused the cloud and on-premises delivered services to fulfil customer expectations across the Nordics.
Prior to joining Ubisecure, John worked for Verizon as a Global Security Product Manager, developing and managing its DDoS platform around the world. With more than 20 years experience in global product management, John is passionate about seamless technology integration. Standing on the shoulders of giants permits us to achieve greatness today and into the future.
More posts by John Jellema