SAML 101

Bart Hendrickx SmallPosted by Bart Hendrickx

As I mentioned in my previous post on SSO, Single Sign-On: Who’s Involved?, we’ll take a look at SAML to understand what it is and how it’s used with SSO. In this post I’ll explain what SAML is, and I will offer an example use case in my next post.


So, What Is SAML?

SAML, or Security Assertion Markup Language, is a protocol that allows systems to exchange authentication data on users. (It facilitates other use cases as well, but I will focus on authentication.) What does that mean? It means that one system can ask: “Who is this user?” and another system can answer: “This is Jane Doe.” As I mentioned in my post previous post, I am talking about the service provider (SP) and identity provider (IdP) respectively.

Service providers (SP) in this context can be any software system with which you can do something, such as sending and receiving email, tracking projects or delivering assessments. Similarly, an identity provider (IdP) can be any software system that contain data on users that you can use to determine who those users are.

If you manage an SP, you probably don’t want just any IdP telling you who someone is. You will typically trust only one or a few IdPs. And if you are in charge of an IdP, you will likewise prefer to send user data only to those SPs you know and trust. To accomplish that, the SP and IdP exchange data allowing them to establishing a trust relationship. Those data are often called federation metadata, federation referring to the fact that there is an alliance between the different systems.

SAML is a popular protocol to set up such federations between service providers and identity providers. Look up SAML in your favorite search engine and you will get many results. One of its advantages is that it is extensible, meaning that you can exchange information that is relevant to your situation. For example, do you have an IdP that stores the hire date for an employee (or enrollment date of a student)? Do you want to share those data with an SP so that it can decide whether the user is allowed to access a certain resource? Then you can set up the federation in such a way that the IdP will send an attribute for hire (or enrollment) date to the SP.

Another advantage, and it is a huge one, is that SAML can be used in situations where the IdP and SP cannot talk to each other, for example because they are on different networks. You may have an IdP running on your internal network, behind a firewall. Your SP may be available in the cloud, as is the case with Questionmark OnDemand. The SP cannot talk to the IdP because it cannot “see” it. However, that’s not a problem for SAML. In my next post, we’ll take a look at a typical use case so we can see the practicality of using SAML with SSO.


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: 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.

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.

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

Bart Hendrickx SmallPosted by Bart Hendrickx

If you manage which users can access your Questionmark environment and define what they can do when they log on, you know that controlling access can take time.

I’d like to take you through a two-part scenario that will demonstrate how to control access efficiently and navigate changes in job roles effectively.

Interested in learning more about role-based security in Questionmark OnDemand? I will be presenting a session on effectively managing users at the 2016 Questionmark Conference in Miami.

Imagine welcoming Ella to your team as a new colleague. She will be using Questionmark, and you want to make sure she has access to those functions of the software she will need—no fewer, and certainly no more. Then you ask yourself: What will Ella be doing? What will be her role?ella

Maybe the answer is along the lines of “she will be replacing Wendy.” Then you might wonder, “OK, so what was Wendy’s role?”

It is natural to think about what people do and the roles they play when you discuss what they should be allowed to do in a software system. And you may be accustomed to using Questionmark Enterprise Manager’s profiles to set things up, by storing a set of permissions in a profile, creating an administrator account and linking the profile to it.

This works well until you come across a colleague who will be actually doing more than one thing (don’t we all?).

“Yes, Ella will be replacing Wendy, but she will also be taking some of Bill’s workload.” You have assigned Wendy’s profile to Ella; she can now run several reports. You want to assign Bill’s profile to her as well. You can’t assign Bill’s entire profile to Ella, but you can compare the two profiles to see where they overlap. It turns out that in addition to what Ella has inherited from Wendy’s profile, Bill can run all reports, so you add the permissions for the remaining reports directly to Ella’s user account.

Two months later, your team restructures some of its operations. “We won’t be running Grade Book reports anymore and we want that permission removed from the users.” You think hard. Who was it that had this permissions? Can’t I just edit the profiles? That won’t update existing users. And what about those users who had the permissions applied directly to them? I can’t judge that merely by the profile that is attached to them.  I’d better edit all those users one by one to be sure.

You stare at the list of almost 50 administrators in your system, decide to get a coffee, sit down and take a breath. This is going to take a while.

In my next article, I will explain how to avoid this pitfall by setting up permissions more efficiently.

Interested in learning more about Role-Based Security in Questionmark OnDemand? I will be presenting a session on effectively managing users at the 2016 Questionmark Conference in Miami, April 12-15. Register by March 3 for a final chance to take advantage of our early-bird discounts…click here to register and learn more about this important learning event. Hope to see you in Miami!