Share This Article
The days where employees sat at workstations and interacted exclusively with native applications are gone but not forgotten: the legacy of singular passwords for services/apps persists, compounding frustrations for IT administrators and users alike.
That’s especially true with cloud infrastructures, where exposing credentials over the wire and the potential for a multitude of weak passwords hampers user productivity and increases risks. There’s a better solution: Single Sign-On (SSO).
What is Single Sign-On (SSO)?
SSO is a solution that many large organizations have adopted to modernize authentication and identity management, as well as achieving frictionless employee onboarding and offboarding. A single, secure password is initially used, but then things start to work very differently.
SSO utilizes SAML, a mechanism that shares identities between organizations and applications. SAML won’t send passwords over the web for every login; it uses a system of secure tokens, instead, which reduces security risks when it’s implemented correctly. Simply put, a ‘passwordless’ future with modern authentication standards like SAML and OAuth is something that should be on your roadmap.
You may be wondering why SSO adoption isn’t universal. The answer is complicated: many small to medium-sized enterprises (SMEs) are mired in legacy directory environments that use the network protocol Kerberos to secure authentication across on-premise networks.
It worked well in that scenario, but today’s IT infrastructures aren’t all local and using passwords to authenticate into every service is essentially solving one problem with another. The password-centric mindset Kerberos established has become detrimental to security, and it’s complex and risky to use for cross-realm deployments (meaning if A trusts B and B trusts C, A might trust C).
You’ll also find that this complicated legacy protocol is difficult to troubleshoot, verify security guarantees, and has a potential for unconstrained delegated permissions downstream. The most pernicious results of this technical debt are: difficult password management, the risk of password reuse, and data breaches that expose those credentials.
All of those things increase your (unaccepted) risks, making data breaches more likely to occur. SSO is a modern, simpler way to address all of those issues, but takes some time to set up.
Candidly, ‘SSO is hard to test’ is another common refrain. You wouldn’t code a web site without viewing the product and conducting shakeout testing before entering production. Your brand, reputation, and user satisfaction would be disadvantaged, and it makes no sense to do that. The same is true for SSO, where:
- At the infrastructure level, information related to endpoints, security, and privacy are exchanged; and,
- At the presentation level, a single credential is created for the sign-on experience.
Testing resources typically aren’t publicly available or are time-limited trials that may not sync with your schedule.
Don’t Wait: SSO should be a high priority
Before we get started: the significance of SSO as a core security requirement isn’t always immediately evident. An overwhelming majority of cyber attacks are “drive-bys” where attackers leverage poor IT hygiene, such as weak passwords.
Complicated Advanced Persistent Threats (APTs) usually aren’t what expose a company’s data and users; a failure to be proactive and adopt modern solutions is. Add to that the difficulty of managing many disparate credentials and user permissions, which gives IT admin’s headaches just thinking about it. The Colonial Pipeline breach is one such example and was a consequence of a one bad password and account that IT had lost track of.
Readily accessible IdPs and testing resources enable you to ‘do it now’, rather than postpone a high-priority project. A standardized priority matrix will help you to make the case internally, based on a system that triages all of your projects with mutual understanding between IT and C-level supervisors, accounting for budget and urgency.
A judicious use of the full capabilities of your IdP, such as SSO, will go a long way toward safeguarding your organization. Adopting SSO should be a priority within your evaluation of any platform for directory and authentication, which is made possible by utilizing the free SAML Test Service Provider (SP).
It makes it possible to fully evaluate the SSO solution before making a purchase, furthering your expertise as well as the confidentiality, integrity, and availability of IT assets that are vital to your business. A breach costs far more than SSO. Using the test SP is easy, and outlined in detail below.
Now, onto the testing work.
The SAML Test Service Provider and Vendor Selection
There are three entities to keep in mind when starting your SSO project:
- The Identity Provider (IdP), (i.e. a directory of users and authentication capabilities)
- The Service Provider (SP), or web application
- A user that has an established account and identity within the IdP.
Testing tools also help, and a free service called SAML Test Service Provider is available free of charge to expedite your SSO efforts. Many IdPs aren’t forthcoming with providing a sandbox for testing purposes, so do your diligence when you select yours. It’s also important to factor in SSO support when you select an SP. SPs can become an obstacle to SSO adoption when pricing exploits your desire for security best practices.
SSO is a critical necessity for organizations with >5 members, not a luxury, but capabilities such as support for SAML are frequently tied to higher tier service levels within web applications (also referred to above as Service Providers).
This is informally referred to as the “SSO Tax”, and makes projects more difficult to justify when costs rise by multiples. Use a SP that offers SSO as a core product feature; otherwise, this vital capability may be out of reach of your organization’s budget.
Another common pain point that the Test Service Provider will address is preparation: SAML makes migration an ‘all or nothing’ proposition. All users must be authenticated via SSO from the onset, so testing your implementation well in advance will pay dividends with a readily available training resource, enabling users to obtain a basic comfort level and competency with the portal log-in process before the switch over.
Getting Started with SAML Test Service Provider
There are two ways to conduct your testing: IdP initiated SSO and SP initiated SSO. JumpCloud is the IdP in this example in combination with the free test provider.
IdP initiated SSO
SAML and IdP Metadata:
The initial step to using the Test Service Provider is via the IdP initiated method. You may obtain SAML metadata from the test SP, which is available here. The metadata is information that describes the service so that your IdP can consume it.
Your IdP will have an interface to create a generic SAML connector (note: IdPs will generally have a library of pre-made connectors ready for commonly used services). This step will integrate your IdP with the SAML testing tool with a default configuration.
The ability to customize its look and feel is outlined here. However, it’s not necessary to customize anything to conduct basic functional testing using the free tool. Here are a few resources that will demystify beginning this process:
- How to work with SAML metadata for ADFS and XML
- Single Sign On (SSO) with SAML 2.0 Connector (Custom SAML App)
SP initiated SSO
Use Metadata from Your IdP
The metadata step is a prerequisite for SP initiated SSO. You’ll be following a similar procedure for SP initiated SSO by downloading (or cutting and pasting) the IdP metadata into the testing tool. It will result in the creation of a unique URL that you’ll be using for logins throughout your testing.
Testing URL
The URL maps back to the IdP, which does the heavy lifting for all identity management and authentication. The instructions stress bookmarking that URL and that accessing it will send a SAML AuthNRequest to your IdP, which is simply a message sent from the SP asking to authenticate a given user’s session.
The IdP metadata import process must be repeated within the tool if you lose it, so it’s advisable to keep it handy throughout the testing duration (don’t worry, there are detailed instructions on the testing service’s web page). The most important consideration is to have an IdP that will allow you to experiment at your own pace.
Ways to Authenticate SSO
The testing site includes additional information but also features a “AuthNRequest Wizard” once a user successfully authenticates that’s displayed at the top of the page. You can use that to determine a specific method of authentication from the IdP (AuthenticationContextClassRef) or flag that the initial authentication has taken place so that the IdP can then select a stronger factor to increase your security.
It’s strongly advisable to use MFA (multi-factor authentication), but to always consider the human side of implementation and day-to-day use. Different forms of authentication are easier and some are harder for the user to master. Push notifications are often described as being the most user-friendly.
SSO Attributes and Customizations
Pick a Color, Any Color
You’ll want a portal that users will immediately recognize and trust with the appropriate branding and color scheme. The testing tool has a feature called “RelayState” that customizes the appearance of the protected page; sets the attribute to a supported color on the IdP side (NameID) or trigger a color change without modifying the configuration by appending the test site’s unique URL — e.g. “https://sptest.iamshowcase.com/protected?color=blue“.
SSO Welcome Messages and Other Customizations
NameID, a SAML attribute statement, is where other customizations, such as a welcome message are set. Additional information about attributes can be found here (PDF download). The testing site provides the following example specific to the tool:
“Hello <firstname> <lastname>”
To get the <firstname> and/or <lastname> populated, it’ll try to find an attribute called “givenname” or “firstname” for <firstname> and “sn”, “lastname”, “surname” or “name” for <lastname>. All this totally ignores the case of the attribute name, so givenName, Givenname, givenname, GiVeNnAmE are all the same (if you think GiVeNnAmE is a good idea… we salute you!)
User Integrity
Please note that the testing tool is for demo purposes only and that some advanced security features aren’t supported at this time, including signed AuthNRequests and encrypted SAML assertions, which is data that’s communicated between the SP and IdP about the user’s authorization status (meaning that you’re a legit user). Details about attributes and attribute statements are otherwise found within the testing tool.
Compliance and Data Retention for SSO
You may also want to log all SAML authentications for compliance if you’re in a regulated industry or your security analysts and IT admins track access to resources. Specific compliance regimes mandate logging access of designated endpoints such as: PCI DSS compliance for cardholder data environments (CDE); HIPAA and personal health information (PHI); and GDPR’s broad view of data stored for EU-based residents.
Conclusion
SAML Test Service Provider removes obstacles to adopting SSO, along with an IdP that offers a sandbox environment that fits your project timeline. It’s advisable to consider whether an SP (web application) provides native, free SAML SSO support prior to selecting that vendor. The risk and expense of not doing SSO is less acceptable as:
- Your organization grows
- It consumes more services
- Legacy Kerberos authentication and passwords prove inadequate for cloud services; AND,
- The cyber security threat environment becomes continually more challenging to control and analyze
Testing is important to be ready for the switch-over to SAML, which is global and could disrupt operations without adequate user acceptance and training.
The benefits of SSO are essential for cloud infrastructure and shouldn’t be relegated to the domain of large enterprises with bigger budgets. You can use a priority matrix template to determine where SSO should sit on your IT agenda: the results may surprise you.
You can try JumpCloud’s SSO service free by starting a trial today.
