About two years ago, I wrote and published a blog on IBM developerWorks, which has been pretty popular and I still get the occasional email asking questions about it. Since IBM developerWorks was sunset, I can no longer update the article there, so if you'll forgive me, I thought that since the blog still resonates, I thought I'd post an updated version of it here......
There’s been lots of occasions over the past couple of years where I have been asked about Single Sign On to the IBM Cloud, or rather Identity Federation. When I was first asked, it prompted me to read up a bit on the subject, make some great new contacts and generally get up to speed!
This post explores some of the basics and will help you to understand what Identity Federation is, how it’s helpful and where to go next.
Single Sign On or Identity Federation?
First, let’s get the nomenclature right. Is this Single Sign On (SSO)? Well, sort of but if we refer to this as Single Sign On in the context of IBM Cloud, it gets confusing quickly. Also, there may be applications that you use in IBM Cloud that are developed and won't 'inherit' a single sign on capability, unless they are set up to work that way, through separate services. What we are talking about in this post is signing onto the IBM Cloud platform itself and not the applications that have been developed there.
If you are an experienced user of the IBM Cloud, you will know that you log onto the platform with your IBMid. This often takes the form of your email address and you then provide a password. Effectively, you have a username and password that is separate to everything else that you have, which you need to remember. Identity Federation alleviates the need to remember a separate username and password by using another Identity Provider to authenticate you.
Identity Provider? This sounds complicated!
Don’t worry, it’s not that complicated. All an Identity Provider does is vouch that you are who you say you are and that you are trusted. Imagine you are out with a friend called Tom and going to Barbara’s house. You’ve never met Barbara before but because Tom and Barbara know each other well, Barbara will welcome you inside because Tom can vouch for you. Identity Providers in Identity Federation systems follow the same concept.
For example, your identity provider might be the organization you work for. By logging into your organization’s systems, you have authenticated yourself and those systems know who you are and trust you. They can then pass this trust onto other systems that trust your organization. Effectively, you are using a single identity – the one you use to gain access to your organizations systems – to access other, separate systems. This is called Identity Federation.
So how does that work in IBM Cloud?
Setting up Identity Federation in the IBM Cloud is not that complex. First, you need to register the domain that triggers the use of the federation service. This will normally be an email address, so for example the ‘ibm.com’ part of my email address triggers the federated sign-on process for my account.
When the IBM Cloud sign-on recognizes that the login is coming from a federated account, it then passes the authentication process back to the Identity Provider. This gives the user a familiar log-in process, particularly when their own organization is the Identity Provider. When the user is authenticated by the Identity Provider, the identity provider passes a Security Assertion Markup Language (SAML 2.0) token back to IBM Cloud. This token contains certain identity information, letting IBM Cloud know that the user is trusted and authorized to use the service. The diagram below shows how this works.
Summary: Why Use Identity Federation?
Identity Federation isn’t suitable for everyone but if you have a large, corporate IBM Cloud account, it can very useful.
- Users don’t need to remember another set of credentials
- The IBM Cloud environment has a more seamless integration into the user’s work environment
- Security is enhanced, since users need access to a company’s sign-in system. This can restrict user location and machine access, as well as enforce password complexity requirements and expiry / reset policies
- When a user leaves an organization, their access to IBM Cloud is removed when they are removed from the organization’s sign-in system
- Identity Federation unlocks Dynamic Rules for Access Groups under Identity and Access Mangement
Thanks for reading – this post has provided a very quick overview on Identity Federation for IBM Cloud. To learn more, check out the IBMid Enterprise Federation Adoption Guide.