Single Sign-On, Federated Identity & SAML
Information Technology (IT) - 2 March 2016
As part of our monthly SOLABS technology blog series, we’re speaking with our software engineers on their reflections on the industry, its development and rapid changes, and how their area of current focus may be pertinent to compliance/regulatory and the future of EQMS software.
For this instalment, we’re talking with SOLABS’ Software Architect Olivier Kloss, about authentication, federated security, Security Assertion Markup Language (SAML), logging in to compliant software, and the involved challenges in maintaining security and identity in the ‘cloud’.
Introduction: Olivier Kloss, Software Architect
Olivier Kloss has been around since the early days of SOLABS QM, which, when he started, was named Alibaba. During his tenure at the company, he completed an internship, and then rose in rank while working as a developer, completing written functional requirements and documentation, and handling integration and qualification.
As SOLABS QM’s cloud option (offered as Software as a Service or SaaS, alongside our on-premises solutions) becomes the default, integration with various service providers (across both enterprise and hosted software) is becoming increasingly necessary. SaaS providers and Quality Management Software (QMS) vendors alike realize which core features users demand, what comprises the core of their offerings that they should develop in-house, and when a feature—like identity federation—needs to be outsourced, and that’s increasingly the path that is taken.
“A federated identity in information technology is the means of linking a person’s electronic identity and attributes, stored across multiple distinct identity management systems.”1
Olivier Kloss has been around since the early days of SOLABS QM, which, when he started, was named Alibaba (this screenshot is from Aug. 2003, the month Olivier started at SOLABS).
Interview: Single Sign-On, Federated Identity & SAML
Dan Harbridge (DH): As a layperson on the subject of identity federation, I’m going to be speaking in metaphors a lot. With that in mind, logging in or identity protection just seems like a checkpoint—you enter your login and password and get into Gmail, for example—
Olivier Kloss (OK): Right, and by extension, if you go to the comments section of a website (or a retailer), you’ll frequently be asked if you want to sign in/be verified using your Google credentials—using your example—rather than create a password specifically for that site. So in that case, Google is ‘vouching’ for you. The website or retailer has outsourced that part of their identity verification.
DH: So, they’re checking your identity, as say a bouncer at a club would, but what gives Google—in my previous example—credibility, besides that they have your information, they have your IP address, they do this in an https:// session…?
OK: Well, the Identity Provider and the Service Provider (us, in this case) enter into some sort of mutually agreed upon contractual arrangement—bolstered by 3rd party independent audits.
DH: So if and when we federate identity, we’ll have to do it with a reputable provider?
OK: Of course. And how it works is: they sell an identity management server and provide the means to connect to it, in order to implement identity federation between us and the user’s other application.
They provide us with the ‘vouching’ for identities, but it’s transparent to the user. On login, they check the user name and password, and they likely put a token in the browser cache. The user may be temporarily processed through the identity federation—but again, transparently. We all agree on a set of credentials, explicitly or implicitly, and of course that is crucial in regulatory/compliance.
"Within an industry like ours (Life Sciences), where regulatory compliance is a major concern, clients (in our case, a pharmaceutical company, for example) may want to audit the ID provider to ensure their practices meet the stringent standards required."
DH: Well so the bouncer metaphor is not invalid, but maybe over-simplified?
OK: Yes. Sites like Stack Overflow trust third-parties to vouch for you, but do not store password information. Microsoft has Office 365, and that is their implementation—where users are checked against a pre-populated directory. It’s kind of like a phone book or one of those big obsolete card catalogues no one uses any more…
DH: A Rolodex?
OK: [laughs.] Yeah, exactly. So the bouncer is a good analogy, because they don’t ‘know’ you, know your family history, etc., but they can check you out in the lineup; ask you for ID—maybe even a secret handshake or a password, something you might have been asked for at the entry door of a speakeasy in the late 1920s.
So sure, the analogy works, but the standards aren’t what we’re talking about really. The verification of identity is outsourced to a reliable provider by companies for whom identity management isn’t a primary focus of R&D and development.
Within an industry like ours (Life Sciences), where regulatory compliance is a major concern, clients (in our case, a pharmaceutical company, for example) may want to audit the ID provider to ensure their practices meet the stringent standards required. That said, all of a company’s protected, confidential info is not connected to the identity federation implementation. The identity providing company is simply responsible for verification, independently, as part of a string of processes.
The best analogy might be a condo building that hires their own security company; they’ve been trusted to verify that you’re a resident of the property by building management, but they don’t need to check you against personal, confidential information on file every time you enter the building.
Sites like Stack Overflow trust third-parties to vouch for you (Google and Facebook, above), but do not store password information.
DH: I’m curious, when you get asked to read up on or research something, like identity federation, how do you normally proceed?
OK: How do I prepare? First, I get a very basic overview of the subject by reading up on Wikis, and Googling links, and then dig deeper using industry sites, bookmarks I’ve been keeping, industry reports like Gartner, university libraries, forums online, and I may talk to peers at meetings or ask someone if they know someone who has done it.
If ALL that looks promising, I’ll progress further by:
- finding user documentation for developers
- writing use cases
- breaking down use cases into segments
- building a prototype, and
- seeing if they have more than one level of service
DH: Well, I know you’ve worked through these steps in relation to identity federation and integration with SOLABS QM. So, what conclusion have you reached?
OK: In the end, among other things and at this stage, we’re looking at SAML—which is a standard—for now.
But in general, the best providers of identity federation and management provide code samples (something that’s a huge time-saver and something I would recommend other developers look for in a solution), sometimes even shrink-wrapped software with tutorials in one’s desired platform—in our case, it’s Java. There’s still a lot of work to be done before we finalize our decision. I’ll be sure to keep you updated!
DH: Terrific. Thanks for speaking with us, Olivier!