Single Sign-On Best Practices: How Organisations can Implement SSO with Keith Uber, Ubisecure

Let's Talk About Digital Identity

Let’s talk about digital identity with Keith Uber, VP in charge of Sales Engineering at Ubisecure.

In episode 94, Keith joins Oscar to delve into Single Sign-On (SSO) best practises and how organisations can implement SSO – including technical aspects, how it used in practise and the advantages of SSO.

[Transcript below]

“The best type of single sign-on is where the user doesn’t notice it.”

Keith is VP Customer Success at Ubisecure. As an Identity and Access Management product expert, he leads the Sales Engineering team and is involved in many stages in the planning and design of demanding customer implementation projects. Keith is active in various industry organisations and has a keen interest particularly in government mandated digital identity systems. He holds a bachelor’s degree in I.T. and a master’s degree in Economics, specialising in software business.

Check out Keith’s SSO video series.

Connect with Keith on LinkedIn.

We’ll be continuing this conversation on Twitter using #LTADI – join us @ubisecure!

Go to @Ubisecure on YouTube to watch the video transcript for episode 94.

Podcast transcript

Let’s Talk About Digital Identity, the podcast connecting identity and business. I am your host, Oscar Santolalla.

Oscar Santolalla: Hello and thank you for joining a new episode of Let’s Talk About Digital Identity. Single Sign-On is one thing that, today we take it for granted. So, it’s even hard for us to remember when was the first time we have used it. Today, we’ll go a bit deeper into that and in which direction Single Sign-On is going. And for that we have a special guest, who is Keith Uber, VP at Ubisecure. Hello, Keith.

Keith Uber: Hi, Oscar.

Oscar: Thank you for joining us for the second time. So, you have been – two years ago. Two years ago, you’ve been here before talking about mergers and acquisitions. So happy to have you back here.

Keith: It’s a pleasure. Thank you for the invite to come back.

Oscar: Yeah, nice to have you, Keith. And we’d like to hit a few things about yourself. So, you can tell us about your journey to the world of digital identity.

Keith: Yeah. So, my entry into the world of identity probably began around the year 2000 when I had just moved to Finland from Australia. I was working for telco provider, who was in the – around the dot-com boom era had been acquiring lots of small businesses. Lots of startups, they had their own projects and all of these have many different types of identity systems and lobbying systems. And my introduction to that process was – my job was to evaluate different solutions to their problem and ultimately, take part in a commercial pilot to implement a product to solve that problem.

Oscar: Excellent. And I already can imagine that a single sign-on had some role on that. Just guessing that yes, single sign-on is something that. I was really trying to remember when was the first time that I used it and it’s quite difficult. Because it has been coming in different, in different flavours I would say.

Probably the first time I used was in one of my first jobs when, you know, you go to the office – people used to go to the office every day, and today is not, not for everyone at least. And then you sit down, and you login to your computer. You login to the domain and then suddenly, you can access some of the internal applications without logging in again. So that is one of the ways. And then later it came, what we see more often today is the web single sign-on, right? So, several applications.

So, in order to start with the basics, how you define single sign-on in a nutshell?

Keith: Yeah. Single Sign-On is maybe a more technical term that the industry understands. But for the end users, they don’t really understand what the single sign-on means. But they do understand that they don’t want to have to sign in again and again to different parts of the same website or different sections of the same company. So single sign-on is the ability to sign-on once using any form and use that same session information across many different services. For the end user, that’s great. That means that’s one less username and password, or many, many less username and passwords, or many less authentication methods for the user to manage.

And you mentioned the internet, or the web-based applications has a kind of thing they sort of came along. So, a long time ago, we all used to have desktop machines, and we would have PAT [personal access token] client-based applications and we’d even have to sign into those. Early on, there were different solutions for remembering and replaying the usernames and passwords across different PAT client applications. And that’s what we call enterprise single sign-on.

That’s very much faded away as the world has moved to web browser-based applications where people are spending most of their time in a browser or signing into applications based on browser-based technologies.

Oscar: Thinking of we, as normal user, like majority of users, we are using without noticing, right? You might ask people what is single sign-on and not sure or maybe they try to find meaning from the name itself, but it’s everywhere.

So, if you can tell us a bit more how people are using single sign-on, SSO, in practice? So, what are the – how many ways, what are the scenarios? How many scenarios? Or just mention of a few of the most common ones.

Keith: Yeah. So single sign-on in essence is the reduction in the number of times that you have to sign-in to the different services. So instead of signing into different parts of the same website that might be based on different technologies, you only have to sign in once. And then when you transfer to a different section of the website or a different application within an organisation. You’re already logged in, your name appears, and your information appears.

And a lot of what’s happening, or the technology behind that is happening behind the scenes. It’s mainly invisible to the user and that sometimes makes demonstrating single sign-on, for example, quite a boring demo. Because you’re actually removing a lot of the things which you don’t want to see, and the end result is you see nothing. So, the best type of single sign-on is where the user doesn’t notice it.

But there are other advantages. For example, in order to create an account, you only have to create that account once. So, the user registration process is also simplified with a single sign-on. Without single sign-on, you would have to have a registration process for every individual user application. Or at least some way to authorise your account to be used on other applications. So that makes it easier.

And then password reset, or credential management is then simplified. Because instead of having to reset your password in different services, you can reset your password in one spot, and it’s the same password used for many different services.

Oscar: Yeah, indeed, that illustrates the advantages that as you also said is the users don’t notice. It’s well, in a way, invisible once it’s set up.

So, going deeper into, what are the nuts and bolts of single sign-on? I’m sure there are many technicalities behind, but what are the main standards that make single sign-on possible?

Keith: Yeah. So single sign-on doesn’t have to be done using standards. But of course, standards simplify the implementation process and simplify the management of the solution. There’s basically two main standards which are in use today. The older standard is called SAML 2.0. And this is an XML-based standard. A way to transfer information about the user and the login session between different services using public key-based technology. In more recent years, and the more modern technology is what we call OpenID Connect, which is based on OAuth 2.0. Different workflows use different parts of those two standards.

And that’s a JSON-based, REST JSON-based protocol. It implements most of the same use cases, most of the same user flows. But of course, as technology has developed, new use cases have come, now OpenID Connect is what we call the gold standard. Even though it’s the gold standard, there’s still a lot of software systems and products which are based on the SAML 2.0 standard.

So, to truly implement SSO in a – as wide range of target applications as possible, the best thing is to have a solution that supports multiple standards. And there’s ways to bridge between these two standards. So that some applications can use SAML 2.0, and other applications we use OpenID Connect and you don’t have to do a lot of your own development work. Because if the products and the servers support those standards, it’s pretty much plug and play.

Oscar: Yeah, indeed, as you said, two main standards, even though there are other ways, but then two main standards is SAML 2.0 and OpenID Connect. Yeah, even though there are two main standards, there are a lot of software that can make single sign-on happen. We know because from experience being talking with customers, organisations in different sizes. And even though we feel as user that single sign-on is almost ubiquitous. There are still many organisations, companies that don’t have single sign-on or don’t have single sign-on, at least for all the applications.

So, it’s common that there might be in an organisation, let’s say 20 applications and a portion of them, let’s say four of them, which have some similarity, they have single sign-on. But all the rest are disconnected, different identities for that.

So, there is still some technicalities behind putting that in practice from an organisation perspective. So, if you can tell us how organisations can implement SSO. The main step, let’s say, for setting up single sign-on.

Keith: Yeah. What you described is a common scenario that even a company that’s implemented SSO in their environment. There could be a lot of applications which are outside of the system, either they’ve been implemented by a team that was unaware of the technology or unaware of the how to do it, or the product developers were unaware, the people buying it didn’t know what to ask for. So, there’s a lot of situations where a company can be – have SSO in place for maybe their main applications. But maybe for their own employees or different user groups, such as external suppliers, they might really go back to square one where the users have to log in many, many times.

The best way to implement SSO is to pick the most used applications, that are used by most of your customers. Who are probably requesting that today, especially for consumer customers. The most typical situation is that there’s a main application, it might be a web shop, or some service portal, it’s connected to some other related application such as a support portal or documentation system or something. And these two services are used hand-in-hand and they’re used often buy most of the users. So, you try to work on the principle of bringing in the most used applications that touch the most users sort of in a priority order.

SSO isn’t something that you would implement across the whole organisation and across all applications overnight. It’s done as a roadmap project, where over the lifecycle of different applications, you would plan carefully which applications you’re going to switch on for SSO. That might be on-premise applications or cloud services. It’s important at the very start to do an inventory of the applications which you’re offering to different user groups. Clearly define those different user groups, see what dedication they’re using already today, and then prioritise how you’re going to move them across to a true single sign-on system. It’s something that has to be done bit by bit.

Some applications may need to wait until their supplier switches on SSO or makes it available for the customers. Some cloud services might charge additional service fees for enabling corporate SSO, some might already have that today that’s just not turned on for your organisation.

It’s really good to work with pilot organisations, especially in B2B. And these are probably organisations which are already coming to you, already asking, when will you support my corporate login? When will I be able to click through and not have to log in? When will I not have to synchronise my users with your service, for example?

Because one of the big advantages of SSO, when we’re talking about business-to-business use cases. Is allowing customers, not only to move between their applications that you offer but allow them to use the authentication method which they already have. Which is their corporate login. That might be their own SSO system, or typically today, it’s Azure AD corporate login that they use. Not only for the Windows desktop and cloud services, but you can use it for third party applications as well.

And as the project goes forward and people start to see the benefits, then it becomes a little bit like a tsunami. That then you get requests to switch on every application that you have or to have a goal, to have as many as possible.

Of course, for some applications which are used by a very small user group for a very specific purpose, or very infrequently. The cost and effort of implementing SSO for – even if it’s just configuration, may not be worth the effort or the return. But you’d focus on the high volume, high value applications first.

Oscar: That’s definitely a good observation. High volume applications and the most relevant applications, those are the ones to do first and then gradually all the others.

In terms of best practices that you could give us – let’s do it from two perspectives. From the end users in which might be easier, and then you can go deeper into the – what are the best practices for organisation. So, what would you say to users, either they’re aware or not, they are using single sign-on. But to users who are regularly using single sign-on?

Keith: Yeah. So, for end users, these are the untrained, for example, citizens or consumer users for your services. You have to make it as easy as possible and as simple as possible and use the language that the users understand. So best practices there are to avoid any of the technical terms which are not understandable to begin with. But to make it a very simple and easy process for the user to – for example, register an account, approve terms and conditions, approve attribute consent to allow their information to be processed. To make it easy for them to adopt strong passwords, and have a suitable password policy for the target service.

And then, of course, a way to – or today, it becomes basically standard that you would – enabling a two-factor authentication. Which is familiar for the target audience, something that they’ve done before, they know how to use and something that’s appropriate for the risk, sort of the risk involved in the transaction. You don’t want to have to get the user to do some very complex authentication process just to look at their information. But you might want to have a step-up authentication or a stronger two-factor authentication. For example, in conjunction with some high value transactions, such as a bank transfer or termination of an account service.

My recommendation for end users is just to remember that it has to be understandable and easy to use and configure or design the system accordingly.

Oscar: And for organisations?

Keith: For organisation, it’s really important that the whole process and the whole project around single sign-on is very, very well documented. It’s a core part of security for the applications. It should be regularly reviewed, to understand is it keeping up with the latest threats in the environment? Part of that review is not only the paperwork review of the policies and configurations. But regular automated reviews of logging events, things that happen in the system to trigger evidence of potential attacks or anomalies in the processing. And to address those swiftly and quickly to make sure that there’s no impact on the organisation.

So, it’s important that you dedicate adequate resources either within the organisation or through a partner. Not only through the implementation project, but through the ongoing day to day running of the system. To understand the responsibilities of who is responsible for what and who is monitoring and actioning those events.

Of course, for organisations, one of the downsides for single sign-on is that in some ways, you put all of your eggs in one basket. That if the single sign-on system fails for one reason or another, it can become a single point of failure. But it’s a risk that could prevent users from signing in, and it could prevent customers from buying things. It could prevent customers from moving to a new application within their session.

So, it’s important when the system is scoped and system is implemented, that’s taken into consideration. So, it’s highly available, works at a high performance, can deal with any sort of attacks from the outside world. Because it was, it becomes, in a sense a front door for the organisation. So not only does it have to be welcoming for the user community, and easy to use. But it has to be very well hardened, with very strong locks, so that you’re not a victim of any kind of organised attack on the system.

Oscar: Absolutely, it’s very good that you emphasize this importance of hardening the systems that are – which single sign-on has been built. As you put a piece of software and behind there’s a lot of infrastructure servers. Everything has to be well-secure indeed. Even though, as you see, we haven’t talking about this easiness of its function, single sign-on. It sounds like a solution that you just switch on, and it’s ready. But it’s very good that you emphasize all these security and availability aspects, because it’s so important.

Keith: On that topic, the standards, for example, SAML 2.0, OpenID Connect. They give you a lot of protection. They have well-defined and reviewed and audited protocols and flows, which have been tested and seen the test of time. But even though the specification says something, it’s the implementation which has to be examined. So, it’s very easy for somebody to make a simple mistake, which can put either an individual application or the whole system at risk. For example, incorrectly validating a signature, or looking at the incorrect audience information or so on.

So particularly where in the coding is done by an individual team, it’s important to have the technical reviews and technical audits and importantly, testing of those solutions. Luckily, especially for OpenID Connect there is very, very powerful tools for automated testing of implementations. Which is a great way to give yourself faith in an implementation. To see how it complies with the various risks involved in poor implementation quality.

Oscar: Such tools that – for instance, in especially in the OpenID community there are these, of course products of several years of, I don’t know thousands of organisations contributing to that standard. So, and there has been, of course, evolution of those standards.

So, seeing also the evolution of the standards behind SSO and what other functionality that comes along with single sign-on. What do you see today are trends related to single sign-on?

Keith: Yeah, I think single sign-on is quite mature in terms of, how if for generic single sign-on, for example, for web applications, moving between one application and another. What’s interesting is multi device single sign-on when you’re, for example, signing into a setup box using your mobile phone or signing into applications across devices where a session will follow you.

Today, we’re seeing the better understanding and the commercial release of passkeys. So, this is the culmination of years and years of work on standards such as WebAuthn and the FIDO Alliance standards. Which is now finally wrapped up into consumer understandable services which we know as passkeys. And that kind of takes the user out of the equation when we’re creating – it’s no longer creating passwords of a passkey. They don’t have that risk of creating a credential which is too weak. It’s all, in a way automated and easy to understand. And I think that’s a really exciting thing.

Something new for users to understand how to manage their own collection of passkeys, their own wallet. And how to keep that safe and be able to recover if they lose or break their device. It has its own challenges, but that’s probably the latest, biggest trend. It doesn’t mean that you use the same passkey for every service, still you have a different passkey for every service. So, it’s not like all of the different services are connected in that way. So, it’s privacy protecting.

The related technologies, which I think is a current trend is more of an authentication method. Which is used for single sign-on systems, is related identity wallets. Which are now really starting to come into the public use. Where an organisation can issue a credential and assign that credential and the user can be asked to present that at various services. And they can present as much or as little information as they want. And the service receiving that information can be sure it’s issued by the organisation that issued it.

It’s really exciting, the EU identity wallet projects will bring that into the forefront as more and more governments adopt those type of services. And we’ll see that, we’ve seen that already with, for example, electronic driver’s licenses and electronic professional credentials. So, they will spread, and it will make things easier, I think, for the user. A lot of time and effort into hiding the complexity and the security beneath it all and making the user experience friendly and familiar. Using the service logos and branding and colours and the analogies to cards that you have and so on. So, it’s a big thing.

And this might also drive many, many single sign-on projects. As customers won’t know how to ask for single sign-on, but they say, “Why Can’t We? Why can’t we sign into all of these applications with a passkey instead of using individual credentials for each service?” Those discussions become the underlying discussion of a single sign-on set up with passkeys and authentication method.

Oscar: Yeah. I’m sure the user will be pushing the companies or organisations to deliver single sign-on now that these technologies, passkeys and wallets are reaching that usability level. That it’s ready to be used for the masses.

Final question for your Keith, for all business leaders listening to us now, what is the one actionable idea that they should write on their agendas today?

Keith: I think for single sign-on, one of the related technologies is what’s called federation. And federation is when you have single sign-on across organisational boundaries. So, for example, I could sign in using my Ubisecure login into a third-party application where I do work, for example, with other companies. And this federation signing in with your own commercial credentials across organisational boundaries is something that I think a lot of organisations haven’t benefited from enough today. And that would be – maybe my actionable idea is to look at the B2B applications that you have. Look at the time it takes to manage the users in those systems. For those users to get an account, those users to ask for access, for audits to be done. How do you check what the company is? Are they still in operation? Does that person still work for the company?

A lot of those problems can be solved by implementing cross organisation single sign-on – this federation. And it can be as simple as entering your email address and then signing in using the – or approving the login using your existing home organisation single sign-on. Or are signing in using, Azure Active Directory sign in. In that way, the target application or target organisation gets all of the up-to-date information about the user that they were allowed to get or that they requested to get. They get evidence that the user has a continued relationship with that organisation. And of course, they get single sign-on, so they don’t actually have to sign in again. They might just approve the login and get to work.

It’s got benefits for all parties in the transaction. It improves security, it improves the auditing. It’s easier to use. It’s convenient, less hassle, less clean up, less risk. And I think it’s not anything new in terms of technology, but it’s something that’s underutilised and maybe undervalued.

Oscar: Yeah, I agree with that. I think organisations could use more to fulfil the potential of more collaboration between organisations. By using these techniques that there has been for a while, and we have been discussing today.

Thank you very much, Keith, for joining us today. It has been super interesting to hear more in detail what single sign-on can do for different types of organisations. And of course, ultimately, to make our lives and users life much easier. So, if someone would like to follow this conversation with you, what are the best ways for that?

Keith: Best way to keep in touch with what I’m doing and what Ubisecure is doing is through our website at www.ubisecure.com. There you can register for various newsletters and so forth. I’m not so active in social media in recent years, but I do have a Twitter handle @KeithUber. Through the Ubisecure Twitter, @ubisecure, we’re happy to engage and participate. We share lots of ideas, including this very good podcast and related interviews.

Our team is also responsible for the IAM Academy Training Program. The IAM Academy Training Program is a way that we share our knowledge with our customers, partners, and anybody who is interested in learning more about the nuts and bolts, the policies and practices of Identity and Access Management and Consumer Identity and Access Management. We run that training various times over the year. And that’s a great way to have a deep dive into the field. So, I welcome you to register for IAM Academy, which is also through our website at www.ubisecure.com/iam-academy/.

Oscar: Yeah, absolutely. Very welcome to join us in IAM Academy. Well, I’ll be there if you join us. So, fantastic. Again, thank you very much, Keith, for joining us in all the best.

Keith: Thanks Oscar. It’s my pleasure.

Thanks for listening to this episode of Let’s Talk About Digital Identity produced by Ubisecure. Stay up to date with episode at ubisecure.com/podcast or join us on Twitter @ubisecure and use the #LTADI. Until next time.