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.


LTI and the future of learning management systems

Jeff Place at the Questionmark booth at The Blackboard Developer Conference

Posted by Steve Lay

Following along with the twitter feed at #devcon12 (The Blackboard Developer Conference) this week, I noticed an interesting theme developing. Here’s one example, from @certtechpro

More LMS’s in the future, but using the same tools? Will LMS of the future be specialized? #devcon12 #bbw12

And another, from @rossmackenzie

Interest theme developing about specialised ( e.g. Subject specific) Learning management systems. #devcon12 #bbw12

These tweets happened during a keynote panel session that grappled with the role of the LMS and the effect that adoption of the IMS LTI standard will have.

I had a follow-up conversation with two members of the panel afterwards to help get some clarification on their vision. In particular, I wanted to reconcile this multiplicity of LMSs with another theme discussed during the session: the importance of ensuring that the LMS does not just aggregate new features but “hardens” around core functions, with additional features being incorporated by linking to other tools using IMS LTI.

Using the LTI standard, the LMS can aggregate best-of-breed tools rather than having to develop them specifically as features of the LMS itself.

There seem to be two possible outcomes here:

(1) By being smaller, the LMS could be customised to target specific education or training sectors; it could even be optimised for subject-specific learning methods. The number of LMSs in the market would increase.

(2) Alternatively, by being smaller the LMS could fade into the background, with student interaction being concentrated in the tools that the LMS aggregates. The community is likely to organise itself around a smaller number of more robust systems.

In either case, integration using the LTI standard will make it easier for instructors and programme managers to adopt best-of-breed tools like our own Assessment Management System without having to deploy an LMS-specific connector!