SAML 101: How it works

Bart Hendrickx SmallPosted by Bart Hendrickx

In my last post, I wrote about what SAML is. In this one, I’ll offer a use case to put it into context. There are a number of scenarios where SAML can be used, but I will stick toSSO3 login (authentication) that is initiated by the service provider. I’ll use Questionmark OnDemand as an example of a SP that can work with SAML. Our fictitious customer has an identity provider that is internally hosted behind a firewall, inaccessible from the outside world. Users at the customer’s company can go on the Internet; therefore, they can also take Questionmark OnDemand assessments.

User Jane Doe wants to connect to Questionmark OnDemand, to take an assessment that was scheduled to her. She browses to her company’s OnDemand area, which had been set up to authenticate via SAML. Through the federation metadata, Questionmark OnDemand knows which identity provider to ask for those authentication details. But it cannot talk to the IdP directly. Instead, it creates a SAML request which the web browser passes on to the IdP. Jane Doe’s computer is on the internal network and can access the IdP. The request is forwarded to the IdP, which accepts it because it knows about the service provider (SP), i.e. the customer’s OnDemand area—also possible thanks to the federation metadata.

Jane Doe is already logged on to the IdP: she opened her company’s intranet page this morning, which required her to authenticate, and that session is still active in her browser. So when the IdP gets a request: “Who is this user?”, it already knows the answer: “This is Jane Doe.” The IdP prepares a SAML response and includes a number of attributes, such as Jane Doe’s email address and hire date. All those data form an assertion, which is part of the response.

Again, Jane Doe’s browser plays a key role. It receives the SAML response with the assertion from the IdP and passes it on to the customer’s OnDemand area, which then reads the response. The OnDemand area confirms that this information comes from its trusted IdP and sees that this is Jane Doe. and that an assessment has been scheduled to her. Jane Doe now has access to the OnDemand area and can take the assessment.

For Jane Doe, this all happens seamlessly. She may see her browser redirect to other URLs a few times, when it is relaying information from the SP to the IdP and vice versa, but the entire process usually only takes a couple of seconds.

In a future post, I will explain what SAML requests and responses do and do not contain. Stay tuned!

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.


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.


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.

Single Sign-On Pros and Cons

Bart Hendrickx Small

Posted by Bart Hendrickx

In my previous blog post on Single Sign-On (SSO), I touched on advantages and disadvantages of using SSO. In this blog post, I will revisit and expand on those. I hope they will help you decide whether SSO is something you would like to use within Questionmark OnDemand, your organization or project.

My colleague Christian Röwenstrunk used the following image in his presentation on SSO at Questionmark Conference 2016, which sums it up well:


SSO Advantages

  1. SSO reduces password fatigue. When you need to remember one password for your identity provider, instead of multiple passwords for each of the different systems (service providers) you want to connect to, you get less tired of having to fill out passwords each time you log on to a system. It is a better user experience.
    Let’s admit it, if you need to maintain ten passwords for ten systems, you are inclined to choose passwords that are variations of one another which can be insecure. Or, worse, you use the same password on all systems (never do that!). If you need to remember only one password, you are also more willing to invest more energy in coming up with a more secure password.
  2. SSO reduces password exposure. When you need to enter your password once (cf. “Single” in Single Sign-On), there is less risk that someone will shoulder surf and see your password.
  3. SSO simplifies user and password management. This is especially interesting for the IT department. If you can access multiple systems as part of your employment, and you leave the organization, the IT department only needs to decommission your account on the identity provider to revoke your access to all the service providers.
  4. SSO opens up new possibilities. Identity providers often have capabilities that make authentication more secure. For example, if your identity provider supports multi-factor authentication, then you can leverage that capability for all the service providers that are linked to your identity provider.

SSO Disadvantages

  1. SSO gives you the keys to the castle. If you log on to multiple systems from one identity provider, and a hacker compromises your user account on the identity provider, the hacker gets unauthorized access to all the linked systems. This is similar to using the same password for multiple systems.
  2. SSO does not work when your identity provider is down. If your identity provider does not respond, for example due to an outage, you cannot log on to any of the systems that are linked to it.
  3. SSO takes a little bit of investment to set up. Linking your identity provider to a service provider is an extra step. Depending on the technologies used and the use cases, that extra step can mean that you will spend some time setting things up.

Single sign-on: secure and easy access

Bart Hendrickx Small

Posted by Bart Hendrickx

It’s Tuesday morning. You have just started your computer. Now it’s time to open your day-to-day tools: email, chat/phone, tasks and so on. As you go through your tasks, you realize you need to take that data security test you’ve been postponing.

Every day, you interact with various applications. Some are installed on your personal computer, others on servers managed either by your organization by vendors.  Your applications might come from a multitude of service providers, in-house or on the Cloud.

For many of those applications, you need to authenticate—to tell the applications who you are—so that the app can present the information that pertains to you. Sometimes this happens automatically. When your email client connects to the mail server, you read your emails, not those of your co-workers. Your email client has authenticated you against your mail server because you entered a username or email address, a password and some other data, way back when.

You often need to use different sign-ins for different apps. When you log in tor you Questionmark OnDemand portal, for instance, you enter a different username and password than the one you used to unlock your computer earlier today, (Your organization’s data security policy does not allow you to  store your organizational password in other systems.)

Want to learn more? I’ll be discussing this topic and more at the Questionmark Conference 2016 in Miami, April 12-15. Register before March 3 to take advantage of our final early-bird discounts.

Problem: Unrecognized username or password

You’ve logged in for your exam, but you get an error message. Maybe you mistyped the password? Second try. Nope; same results. You must have forgotten your password. You start an instant message window with your internal IT help desk. “Sorry, we don’t manage Questionmark OnDemand. Can you use its password reset function?”

You go back to your Questionmark login page, get a secure on-time login and establish a new, permanent password that complies with the data security policy — “I better not forget my password this time,” you say to yourself as you finally start your data security test. “Isn’t there something more convenient?”

Solution: Single sign-on

We all find ourselves in similar situations, but with Single sign-on (SSO) we can avoid them.

Since, there are several definitions of SSO, here’s how I’ll define it in the context of this blog:

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.

By identity provider, I mean a system that contains digital identity information—also known as people data—on users, For example, think of social network sites or Active Directory from Microsoft.

The service provider is the system that users work with to do something—say Questionmark OnDemand, in the case of your data security test.

With SSO, a user does not log on directly to the service provider. Instead, they log on to an identity provider, which then tells the service provider who the user is. The identity provider and service provider have been configured to trust each other. So when the identity provider says: “This is Jane Doe,” the service provider will trust and accept that.

It is important to note that SSO is therefore not about creating accounts with the same usernames and passwords—a prevalent mechanism for different service providers. SSO is about making those service providers accept what an identity provider says about a user.

Why SSO?

SSO comes with several advantages. Users can access all applications that are linked to their identity providers—using one username and password for multiple systems. Depending on the capabilities of the applications and how things have been set up, the authentication can be seamless. You might log on to your identity provider when you start your computer, and the other applications (service providers) you access during the day will automatically check with your identity provider without you having to enter your username and password again.

SSO makes password management easier for IT administrators. Having an employee leave an organization might mean having to decommission access to dozens of service providers. If the authentication to those service providers has been set up with SSO, then an IT administrator only needs to decommission the employee’s identity provider account. Without that account, the employee can no longer log on to any of the linked applications.

There is one disadvantage to SSO: If the account at the identity provider is hacked, all linked applications can be compromised. It is therefore imperative the account is properly secured. How can you set up SSO to ensure its security and effectiveness? Watch for more posts on this subject, which will include information about our newly added support for a popular technique called SAML.

If you would like to learn more, attend my session: Secure Authentication: Accessing Questionmark OnDemand with SSO at the Questionmark Conference 2016, April 12-15. Register before March 3 to take advantage of our final early-bird discounts.