Single Sign-On: Who’s Involved?
Posted by Bart Hendrickx
This is the third post in a series on single sign-on (SSO). Go here for posts 1 and 2:
In my first post, I offered this definition for SSO:
Single Sign-On (SSO) for software is the ability for one application, the identity provider, to tell another application, the service provider, who you are.
As you can gather from that definition, SSO involves two parties: the identity provider and the service provider. That is not the complete picture. In many cases, there is also the user and the user agent.
In this post, I explain who those parties are.
Service Provider (SP)
The service provider (SP) is the system a user wants to do something with. For example, Questionmark OnDemand: the user can be a participant who wants to take an assessment. Questionmark OnDemand provides the service of delivering an assessment that the user can take.
When single sign-on is set up, the SP relies on another system to authenticate a user. Therefore, the service provider is also called the relying party (RP). To keep things simple, I will stick to using “SP”.
Identity Provider (IdP)
You know that the SP relies on another system for authentication. That other system is called the identity provider (IdP). The IdP provides identity information on a user to the SP, so that the SP can make a decision to let the user in.
There are many systems that can act as identity providers and some systems specialize in identity. You will recognize many of these: Microsoft Active Directory, Google Account, Facebook, Twitter, LinkedIn—the list is very long.
There is nothing special to user: this is simply the person who wants to do something, such as the participant who wants to take an assessment. Well, the user does not need to be a person; it can also be a system. I will continue using the concept of “person” when I talk about “user”, for simplicity. (Did I already tell you I like to keep things simple?)
This party is sometimes called principal.
The user agent is a piece of software, an application, which acts on behalf of the user. That sounds complicated, so let me give you an example. Your web browser is a user agent. When you visit a web page, your browser requests content on your behalf. Is an image referenced in the content? Your browser downloads it, on your behalf. Do you want to submit a form, such as an order with payment details? Your browser sends the information to the website, on your behalf.
In the context of SSO, the user agent often is a browser or an application that can access something on the Internet, such as an app on your smartphone to read emails or access a social network.
The Parties Working Together
Let me bring this together in a picture.
You see a group of users, say, participants who want to take an assessment. They use their web browser, which is a user agent, to connect to the service provider; Questionmark OnDemand in this example.
The service provider relies on an identity provider to say who these users are. In this example, instead of talking directly to the identity provider, the service provider talks to the user agent (browser), who talks to the identity provider. “Who is this user?” the user agent asks the identity provider. The user may need to enter a username and password, on a page which is, you guessed it, displayed by the user agent.
When the identity provider successfully authenticates the user, it responds to the user agent: “This is Jane Doe.” The user agent passes that information on to the service provider, who then decides to give access: “This is Jane Doe and she is a participant; I will make this assessment available to her.”
How can the service provider and identity provider talk to each other, in this case indirectly through the user agent (browser)? They speak a shared language; a protocol that is used to exchange identity information. There are several popular such protocols. I will discuss them in a following post.