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鈥檚 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鈥檚 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鈥檛 send passwords over the web for every login; it uses a system of secure tokens, instead, which reduces security risks when it鈥檚 implemented correctly. Simply put, a 鈥榩asswordless鈥� 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鈥檛 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鈥檚 IT infrastructures aren鈥檛 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鈥檚 complex and risky to use for cross-realm deployments (meaning if A trusts B and B trusts C, A might trust C).
You鈥檒l 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, 鈥楽SO is hard to test鈥� is another common refrain. You wouldn鈥檛 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鈥檛 publicly available or are time-limited trials that may not sync with your schedule.
Don鈥檛 Wait: SSO should be a high priority
Before we get started: the significance of SSO as a core security requirement isn鈥檛 always immediately evident. An overwhelming majority of are 鈥渄rive-bys鈥� where attackers leverage poor IT hygiene, such as weak passwords.
Complicated Advanced Persistent Threats (APTs) usually aren鈥檛 what expose a company鈥檚 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鈥檚 headaches just thinking about it. The Colonial Pipeline breach is one such example and was a consequence of a and account that IT had lost track of.
Readily accessible IdPs and testing resources enable you to 鈥榙o 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 is available free of charge to expedite your SSO efforts. Many IdPs aren鈥檛 forthcoming with providing a sandbox for testing purposes, so do your diligence when you select yours. It鈥檚 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 鈥溾��, 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鈥檚 budget.
Another common pain point that the Test Service Provider will address is preparation: SAML makes migration an 鈥榓ll 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. 黑料海角91入口 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 . 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 (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 . However, it鈥檚 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:
SP initiated SSO
Use Metadata from Your IdP
The metadata step is a prerequisite for SP initiated SSO. You鈥檒l 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鈥檒l 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鈥檚 session.
The IdP metadata import process must be repeated within the tool if you lose it, so it鈥檚 advisable to keep it handy throughout the testing duration (don鈥檛 worry, there are detailed instructions on the testing service鈥檚 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鈥檚 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鈥檚 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鈥檒l want a portal that users will immediately recognize and trust with the appropriate branding and color scheme. The testing tool has a feature called 鈥淩elayState鈥� 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鈥檚 unique URL — e.g. 鈥溾��.
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 (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鈥檛 supported at this time, including and , which is data that鈥檚 communicated between the SP and IdP about the user鈥檚 authorization status (meaning that you鈥檙e 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鈥檙e 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鈥檚 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鈥檚 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鈥檛 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 by starting a trial today.
