Single Sign-On: Who’s Involved?

Bart Hendrickx SmallPosted by Bart Hendrickx

This is the third post in a series on single sign-on (SSO). Go here for posts 1 and 2:

  1. Single sign-on: secure and easy access
  2. Single Sign-On Pros and Cons

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.

User

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.

User Agent

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.

SSO2

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.

Role-Based Permissions: A How-To Guide (Part 2)

Bart Hendrickx SmallPosted by Bart Hendrickx

In my previous post on this subject (How-To Guide Part 1), I described a situation where managing permissions in the classic version of Questionmark Enterprise Manager can quickly turn into a complicated task. The new version of Questionmark, which we are starting to roll out to Questionmark OnDemand customers, offers a more efficient approach: managing permissions based on the tenets of role-based access control.

Interested in learning more about role-based permissions? Drop in on my session on this topic at Questionmark Conference 2016. Register before March 3 to take advantage of our final early-bird discounts.

The principle of role-based access control is that you use roles to define what users can do in the system. You are free to choose what a role is in your organization. You can tie it to a job title and create a role such as Learning and Development Specialist. You can map it to a role on a project team (e.g. the role of setting up a project for an employee satisfaction survey) and create a role like Project Owner. Or you can use any of the default roles that ship with the new version of Questionmark OnDemand, such as Admin and Reporter.

Roles contain permissions. For example, the Reporter role contains a set of permissions to run all reports on all results. When you add that role to a user, that user inherits those permissions. So far, this is similar to how profiles work in the classic version of Questionmark.

The power of the new role-based access control system becomes obvious when you want to give more roles to a user. In the classic version of Questionmark, you can assign only one profile to a user. In the new version, you can assign multiple roles to a user. Do you have a role for creating test items and another one for running reports, and do you have a user who will take on both roles? No problem: assign both roles to the user.

Another advantage of the new role-based access control system is that you can change the permissions of a role, which will automatically trickle down to all users who have that role. Do you want to remove the permission to run a Grade Book report from all users who have the Reporter role? Remove the permission from the Reporter role and you are done.

To ensure there are no loopholes, the new version of Questionmark OnDemand makes it impossible to assign permissions directly to users. Instead, all permissions will be granted within roles.

If you are a Questionmark OnDemand user interested in moving to the new version, contact your account manager. And if you are attending Questionmark Conference 2016, April 12-15, feel free to drop in on my session on this topic. Register before March 3 to take advantage of our final early-bird discounts.