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. <\/p>\n\n\n\n
That\u2019s 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\u2019s a better solution: Single Sign-On (SSO)<\/a>.<\/p>\n\n\n\n SSO utilizes SAML<\/a>, a mechanism that shares identities between organizations and applications. SAML won\u2019t send passwords over the web for every login; it uses a system of secure tokens, instead, which reduces security risks when it\u2019s implemented correctly. Simply put, a \u2018passwordless\u2019 future with modern authentication standards like SAML and OAuth<\/a> is something that should be on your roadmap.<\/p>\n\n\n\n You may be wondering why SSO adoption isn\u2019t 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. <\/p>\n\n\n\n It worked well in that scenario, but today\u2019s IT infrastructures aren\u2019t 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\u2019s complex and risky to use for cross-realm deployments (meaning if A trusts B and B trusts C, A might trust C). <\/p>\n\n\n\n You\u2019ll 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<\/a>, and data breaches that expose those credentials. <\/p>\n\n\n\n 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.<\/p>\n\n\n\n Candidly, \u2018SSO is hard to test\u2019 is another common refrain. You wouldn\u2019t 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:<\/p>\n\n\n\n Testing resources typically aren\u2019t publicly available or are time-limited trials that may not sync with your schedule.<\/p>\n\n\n\n Complicated Advanced Persistent Threats (APTs) usually aren\u2019t what expose a company\u2019s 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\u2019s headaches just thinking about it. The Colonial Pipeline breach is one such example and was a consequence of a one bad password<\/a> and account that IT had lost track of.<\/p>\n\n\n\n Readily accessible IdPs and testing resources enable you to \u2018do it now\u2019, 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.<\/p>\n\n\n\n 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). <\/p>\n\n\n\n It makes it possible to fully evaluate the SSO solution<\/a> 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.<\/p>\n\n\n\n Now, onto the testing work.<\/em><\/p>\n\n\n\n There are three entities to keep in mind when starting your SSO project:<\/p>\n\n\n\n Testing tools also help, and a free service called SAML Test Service Provider<\/a> is available free of charge to expedite your SSO efforts. Many IdPs aren\u2019t forthcoming with providing a sandbox for testing purposes, so do your diligence when you select yours. It\u2019s 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.<\/p>\n\n\n\n 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).<\/p>\n\n\n\n This is informally referred to as the \u201cSSO Tax<\/a>\u201d, and makes projects more difficult to justify when costs rise by multiples. Use a SP that offers SSO<\/a> as a core product feature; otherwise, this vital capability may be out of reach of your organization\u2019s budget.<\/p>\n\n\n\n Another common pain point that the Test Service Provider will address is preparation: SAML makes migration an \u2018all or nothing\u2019 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.<\/p>\n\n\n\n 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.<\/p>\n\n\n\n The initial step<\/strong> 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<\/a>. The metadata is information that describes the service so that your IdP can consume it. <\/p>\n\n\n\n Your IdP will have an interface to create a generic SAML connector<\/a> (note: IdPs will generally have a library<\/a> of pre-made connectors ready for commonly used services). This step will integrate your IdP with the SAML testing tool with a default configuration. <\/p>\n\n\n\n The ability to customize its look and feel is outlined here<\/a>. However, it\u2019s 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:<\/p>\n\n\n\n The metadata step is a prerequisite for SP initiated SSO. You\u2019ll be following a similar procedure for SP initiated SSO by downloading<\/strong> (or cutting and pasting) the IdP<\/strong> metadata<\/strong> into the testing tool. It will result in the creation of a unique URL<\/strong> that you\u2019ll be using for logins throughout your testing.<\/p>\n\n\n\n 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\u2019s session.<\/p>\n\n\n\n The IdP metadata import process must be repeated within the tool if you lose it, so it\u2019s advisable to keep it handy throughout the testing duration (don\u2019t worry, there are detailed instructions on the testing service\u2019s web page). The most important consideration is to have an IdP that will allow you to experiment at your own pace.<\/em><\/p>\n\n\n\n The testing site includes additional information but also features a “AuthNRequest Wizard<\/strong>” once a user successfully authenticates that\u2019s 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.<\/p>\n\n\n\n It\u2019s strongly advisable to use MFA (multi-factor authentication), but to always consider the human side of implementation<\/a> and day-to-day use. Different forms of authentication<\/a> are easier and some are harder for the user to master. Push notifications<\/a> are often described as being the most user-friendly.<\/p>\n\n\n\n Pick a Color, Any Color<\/p>\n\n\n\n You\u2019ll want a portal that users will immediately recognize and trust with the appropriate branding and color scheme. The testing tool has a feature called \u201cRelayState\u201d 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\u2019s unique URL — e.g. \u201chttps:\/\/sptest.iamshowcase.com\/protected?color=blue<\/a>\u201c.<\/p>\n\n\n\n NameID, a SAML attribute statement, is where other customizations, such as a welcome message are set. Additional information about attributes can be found here<\/a> (PDF download). The testing site provides the following example specific to the tool:<\/p>\n\n\n\n “Hello <firstname> <lastname>”<\/p>\n\n\n\n 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!)<\/p>\n<\/blockquote>\n\n\n\n Please note that the testing tool is for demo purposes only and that some advanced security features<\/strong> aren\u2019t supported at this time, including signed AuthNRequests<\/a> and encrypted<\/a> SAML assertions<\/a>, which is data that\u2019s communicated between the SP and IdP about the user\u2019s authorization status (meaning that you\u2019re a legit user). Details about attributes and attribute statements are otherwise found within the testing tool.<\/p>\n\n\n\n You may also want to log all SAML authentications<\/a> for compliance if you\u2019re in a regulated<\/strong> 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\u2019s broad view of data stored for EU-based residents.<\/p>\n\n\n\n SAML Test Service Provider removes obstacles to adopting SSO, along with an IdP that offers a sandbox environment that fits your project timeline. It\u2019s 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:<\/p>\n\n\n\n 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.<\/p>\n\n\n\n The benefits of SSO are essential for cloud infrastructure and shouldn\u2019t be relegated to the domain of large enterprises with bigger budgets. You can use a priority matrix<\/a> template to determine where SSO should sit on your IT agenda: the results may surprise you.<\/p>\n\n\n\nWhat is Single Sign-On (SSO)?<\/h2>\n\n\n\n
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.<\/p>\n\n\n\n\n
Don\u2019t Wait: SSO should be a high priority<\/h2>\n\n\n\n
Before we get started: the significance of SSO as a core security requirement isn\u2019t always immediately evident. An overwhelming majority of cyber attacks<\/a> are \u201cdrive-bys\u201d where attackers leverage poor IT hygiene, such as weak passwords.<\/p>\n\n\n\nThe SAML Test Service Provider and Vendor Selection<\/h2>\n\n\n\n
\n
Getting Started with SAML Test Service Provider<\/h2>\n\n\n\n
IdP initiated SSO<\/h3>\n\n\n\n
SAML and IdP Metadata:<\/h4>\n\n\n\n
\n
SP initiated SSO<\/h3>\n\n\n\n
Use Metadata from Your IdP<\/h4>\n\n\n\n
Testing URL<\/h4>\n\n\n\n
Ways to Authenticate SSO<\/h2>\n\n\n\n
SSO Attributes and Customizations<\/h2>\n\n\n\n
SSO Welcome Messages and Other Customizations<\/h3>\n\n\n\n
\n
User Integrity<\/h3>\n\n\n\n
Compliance and Data Retention for SSO<\/h2>\n\n\n\n
Conclusion<\/h2>\n\n\n\n
\n