Leo Barcenas, Sr. Software Engineer, Pilgrim Quality Solutions
Last month we published the Basics of Federated Single Sign-On (FedSSO). This article will discuss Single Sign-On for federated authentication a bit deeper and explore what we learned by implementing and integrating SmartSolve to Identity Providers (IdP).
FedSSO (Federated Single Sign-On) Background
Federated Single Sign-On is a combination of two concepts: Federated Identity and web-based Single Sign-On. Federated Identity is the ability to link different applications or services with their mutual users. It provides a way for partner services to agree on a common and shared definition about the identity of a user authorized to use a service. There is only a single credential for each user. Federated Identity provides a simpler and easier way for administrators to manage and secure users. It also makes it easier for users to manage their credentials.
Web-based Single Sign-On is the ability of a user to authenticate from one web site and (without further authentication) be able to access resources from another. The authenticating web site is referred to as the Identity Provider (IdP), and the other is the Service Provider (SP) which is also referred to as the Relying Party (RP).
Security Assertion Markup Language (SAML) and WS-Federation (WS-Fed) are the leading technologies to implement FedSSO.
Lesson #1: SAML and WS-Federation are not products.
Security Assertion Markup Language (SAML) is a standard that is defined by an XML-based framework for communicating and describing security information, user attributes, and assertions between online business partners. It is developed by the Security Services Technical Committee of OASIS.
WS-Federation (WS-Fed) is part of the Web Services (WS-*) specifications developed jointly by IBM and Microsoft. WS-Fed does two things:
- It simplifies the development of federated services in which a Resource Provider (in our case, SmartSolve) describes a set of attributes, and,
- It allows access to a specific resource and an Identity Provider (IdP) by asserting that the user possessing those attributes is who he claims. But, it does so without revealing the actual identity of the user.
To put these two factors in context, let’s consider an offline example. Think about your credit card. When you applied, your card company examined your credentials in order to approve your application and extend credit. Now your card company is your Identity Provider and your user attributes are the 16 digit card number and your CVV (the three digits on the back). When you make a purchase, the store—the Service Provider in this example—accepts your user credentials (credit card) and interacts with the Identity Provider on your behalf. The transaction is completed without revealing your personal identity information (address, social security number, etc.) or your personal ability to pay based on your credit limit and current balance because the store (SP) validates with the credit card company (IdP) that your credit card (user attributes) is valid.
There are products and services that implement either SAML or WS-Federation or both. Among these are Microsoft’s Active Directory Federation Services (ADFS), Okta, and Ping Identity to name a few. Typically, our customers have already pre-selected their preferred vendor prior to integrating to SmartSolve, Pilgrim’s quality management software suite.
Lesson #2: Where does FedSSO fit in FDA’s Title 21 CFR Part 11?
SmartSolve is built to improve regulated companies’ processes and practices for the Life Sciences and other highly regulated industries. Among these regulations is the FDA’s Title 21 CFR Part 11. One of its key requirements is electronic signatures. It says in Sec. 11.200 electronic signature components and controls:
“(1) Employ at least two distinct identification components such as an identification code and password.”
In SmartSolve, the minimum electronic signature required is for a user to enter their username (identification code) and password.
FedSSO provides centralized identity management and the flexibility for customers to choose the type of authentication. Most IdPs already support the username/password as the most basic form of authentication.
Furthermore, FDA recommends multi-factor authentication to improve the security of electronic signatures. By centralizing identity management, the IdP can implement multi-factor authentication relatively quickly and simply. SmartSolve customers using FedSSO can easily use multi-factor authentication if they decide to implement it. This applies whether the IdP is using SAML SSO or WS-Fed.
Lesson #3: IdP-Initiated is convenient but SP-Initiated is essential.
In FedSSO there are two distinct behaviors in which Single Sign-On (SSO) or Single Log-out (SLO) is initiated. They are referred to as IdP-Initiated and SP-Initiated. Some may not see the need for both as they accomplish the same thing, and instead choose to implement only one. However, the subtle difference can make the integration more challenging. This could potentially affect the initial cost of implementation in terms of support and opportunity costs. Let me describe what these two behaviors mean and why it impacts a quality management software solution such as SmartSolve.
What is Identity Provider (IdP)-Initiated?
IdP-Initiated SSO or Single Log-Out (SLO) simply describes that the user starts the sign-on from the IdP. FedSSO provides the capability for users to authenticate from the IdP and gives the flexibility for users to choose the applications they are authorized to access. The IdP typically provides a portal-like interface which makes it easier for users to navigate to multiple applications. This convenience is a great feature for users, especially if the company has hundreds of applications in use, which may include our SmartSolve suite of enterprise quality management products.
What is Service Provider (SP)-Initiated?
SP-Initiated SSO (and SLO – Single Log Out) is the reverse of IdP-Initiated. Users can navigate from the application they need to use by way of (but not limited to) bookmarks or direct user access. The SP is configured to detect an authenticated user. If the request is not authenticated, the SP will forward the request to the IdP asking for the user to be authenticated. The IdP will then ask the user for credentials and when properly authenticated, sends back secure information to the SP. The SP will verify and authorize the user to access resources using the assertions or claims from the IdP.
Why Service Provider-Initiated is essential.
IdP-initiated SSO provides users and administration the convenience of a single-entry to any of its integrated applications. It is understandably easier for administration to manage and monitor users and applications. However, there are two reasons why SP-Initiated is an essential feature and must be enabled:
1. Not all user interactions start from a user opening up a browser.
Among these interactions are links from notifications such as emails, messenger conversations, or a text message. Requiring users to authenticate from the IdP prior to navigating to the link is neither a good user experience nor an efficient use of the user’s time.
2. It is a functional requirement.
Generally, most applications may not need it. However, in a regulated environment where compliance is required (such as with electronic signatures in FDA’s 21 CFR Part 11), SP-Initiated becomes an important feature. In FedSSO, sign-offs mean re-authentication. In SAML SSO, for example, re-authentication can be accomplished by sending a forced authentication to the request. From the perspective of the Identity Provider, the user is re-authenticating from the Service Provider. If the IdP prevents SP-Initiated functionality, then users will have no easy way to sign-off. Therefore, the implementation will not be compliant. It is possible to implement sign-offs without SP-Initiated. But, we strongly recommend SP-Initiated for SmartSolve implementations.
Lesson #4: FedSSO integration is a conversation.
In FedSSO, SP and IdP are entirely different applications and most of the time are hosted on different domains and managed by different teams. Further, each end has its own policies, cultures, priorities, and motivations. When integrating FedSSO, it is best to start early in the project by identifying key stakeholders, resources, and expectations. Some organizations may have a dedicated security team, and it is best to get them involved early in the planning stages. This allows the integration team to address any concerns they may have that could potentially impact the overall project delivery goals.
We also found that building a sandbox infrastructure for the integration is very helpful and highly recommended. This allows both teams to understand and learn the integration process as well as potential technical hurdles and security concerns, while minimizing the impact to the other teams that are implementing the rest of the solutions.
The most important take-away for lesson #4 is that the integration teams must have an open line of communication. There are critical pieces of information both teams need to know to successfully implement the integration on time and within budget. Planning and doing it early make all the difference.
Federated Single Sign-On is among the list of key SmartSolve features and add-ons our potential and current customers frequently request. We built this integration to further enhance our products’ capabilities and to demonstrate Pilgrim’s commitment to quality and continuous improvement. We continue to learn many lessons by integrating SmartSolve to different IdP vendors, and we apply these lessons learned as we integrate more of our customers with FedSSO.
Learn More about SmartSolve
Our compliance-ready platform for Enterprise Quality Management is FedSSO enabled.