Federated Single Sign-On: What you Need to Know

Federated Single Sign-On: What you Need to Know

Kumud Bhattarai, Software Development Manager, Pilgrim Quality Solutions

What is Federated Single Sign-On (SSO), and why does it matter? Guest blogger Kumud Bhattarai explains the basics below. A follow-up post on how Federated Single Sign-On works with 21 CFR Part 11 and a quality management software system will be published next month.

Authentication and Federated Single Sign-On: The Basics

Authentication is the basic process for matching user credentials to the credentials within a file or database before providing authorized access to a program or file. Authentication of a user is usually provided by code deeply rooted in an application.

It is usually performed by taking user input like the login name and password, comparing and authenticating the input against a directory, and allowing the user to access the application upon successful verification of the credentials. This form of authentication is fine in systems that are co-located (within same domain) with the identity provider—the party who provides the authentication. But when the party relying on the authentication (in this case the application) is not co-located with the identity provider, things start to get a little bit tricky.

The usual shortcut would be to copy all the credentials over to the provider that is not co-located and manage multiple credentials. This is indeed a shortcut which has the consequence of forcing users to have more credentials. It can add security risks to the organization as users will typically rely either on weak passwords that they can remember for multiple applications or will have to store passwords insecurely, e.g. “write it somewhere accessible.”

Having multiple credentials also increases the complexity of how each application would present users with different sign-on displays. This situation exposes an underlying deeper issue: the users would be very susceptible to phishing attacks because it increases the sign-on methods that could be spoofed. This situation reinforces a need for allowing users access to applications using Single Sign-On (SSO) as one source of authentication in today’s world where applications are increasingly becoming disjointed from being hosted on premise to the cloud.

For example, in your office you may use Outlook for email access, but when working remotely, you may access an online version of Office 365. Onsite, your Outlook application uses the co-located credentials, whereas logging into the website, you’re redirected to your organization’s single sign-on page which may prompt you for your domain username and password before allowing access to the data.

Federated Single Sign-On: How It Works

Delegating the authentication to the Federated Identity Providers, e.g. Microsoft Active Directory Federation Services (ADFS), and using security tokens (claims) issued by these providers is a novel approach to tackle the problem described above. The application will now no longer have to worry about how to authenticate the user. There is a two-step process for this to work:

1 Authentication:

To identify the user after authentication, the application uses claims issued by an Identity Provider to trust that the user is who he claims he is. This identity provider can be used by multiple applications, and there will not be any reason to synchronize credentials between two systems. The issuer can use any mechanism they trust—be it username/password, smartcard, or biometrics, etc.—to validate the claim for the user.

2 Authorization:

Once the user has been validated, a security token is issued. This token can then be used by any application that is claims based. There is always a trust relation between the issuer and the resource (application); anytime the issuer issues a valid token, the application will accept that claim.

Authentication: An Offline Analogy

This kind of authentication mechanism is not a new concept. An example of this is found during any security check: a user is asked to prove that they are who they say they are—usually by producing a driver’s license or some photo identification as proof. In this case the driver’s license or any photo identification is made by trusted Identity Provider (e.g. the DMV). When the license was issued, the provider (DMV) verified a set of credentials that proved who the person was. Now that claim can be used by that person to authenticate himself.

Single Sign-On in a Software World

In a software application, let’s assume a user wants to view a portal page of an application that requires authentication. When the user launches that URL, the portal will redirect the user to an Identity Provider for getting a claim. The user is then validated by the identity provider, and a claim is issued, and the user is sent back to portal page. The portal page then inspects the claim, verifies that this came from a trusted issuer, and allows the user to login to the portal based on this claim.

Aside from reducing the number of credentials for a user to remember, leveraging single sign-on eliminates the need for IT administrators to store and protect multiple credentials (or to store copies of the credentials locally as we mentioned in the shortcut example above). The result is less vulnerability to phishing spoofs, less time spent on identity management, and a seamless user experience for accessing the application.

SmartSolve and Federated SSO

SmartSolve, Pilgrim’s quality management suite of solutions, allows claims-based authentication, bringing Federated Single Sign-On to the administrators and a single password solution to SmartSolve users.

SmartSolve is a highly configurable platform for achieving compliance with industry regulations across global operations. Based on ISO standards for quality management systems, SmartSolve delivers electronic signatures, validation packs, and electronic reporting to meet a wide array of quality management process needs.

A related post on implemented Federated Single Sign-On and SAML 2.0 is scheduled within the coming month. To receive a notification when it is published, please subscribe to our list.

To learn more about SmartSolve and its Federated Single Sign On capabilities, please contact us.


FTC Consumer Information on Phishing


Learn More about SmartSolve

Our compliance-ready platform for Enterprise Quality Management

SmartSolve for EQMS Success


Kumud Bhattarai

Director of Software Development & Enterprise Architect, Pilgrim Quality Solutions

No Comments

Leave a Comment

Your email address will not be published. Please fill out all required fields.

This site uses Akismet to reduce spam. Learn how your comment data is processed.