If you have bought a single sign-on (SSO) product, how do you know that is operating correctly? That seems like a simple question, but answering it isn\u2019t so simple. Configuring the automated sign-ons will require understanding of the authentication protocols they use. You will also need to know how your various applications use these protocols\u2014both on-premises and SaaS\u2014to encode them properly in the SSO portal.\n\nWhile the major SSO vendors support hundreds of apps, some of them\u2014especially your own home-grown ones\u2014may not already be in their catalogs. This means you might have the non-trivial effort to write your own custom login scripts. Some SSO vendors have tools or consultants (available either as part of the initial purchase or for an extra fee) to help with this.\n\nWouldn\u2019t it be nice if you could run an automated testing tool to find out where you slipped up, or where your SSO software is failing? This can be useful in three scenarios:\n\nTo cover all these scenarios, you have two basic choices: The first is to use the testing tools written by your SSO vendor. The problem is that finding these tools isn\u2019t easy. Many vendors treat these tools as more of a side development project rather than something that they offer with their mainstream product lines.\n\nThe second choice is to consider a third-party testing tool. A growing collection of these tools can help you determine if you have set up the numerous variables, cryptographic tokens, and policies correctly. The caveat is that they work with only a few of the SSO products\u2014at least so far. While the absence of a test tool shouldn\u2019t sway your SSO purchase decision, it\u2019s good to know if one is available for your eventual implementation.\n\nAnother option is to employ a cloud access security broker (CASB) tool. These do other things beside automate the login to your SaaS apps, such as add another security layer.\n\nTesting tools from major SSO vendors\n\nWhen you first stand up your SSO implementation, you typically have a small test group of users to ensure that it is working as intended for a small sampling of your apps. Some SSO vendors can create a test environment to work out the bugs, such as provisioning and deprovisioning users, and identifying unknown apps (or at least unknown to the IT organization) that will need further attention.\n\nHere is where things get interesting. If this is your first exposure to the Security Assertion Markup Language (SAML), OpenID Connect, and Open Authorization (OAuth) protocols, you will want to have some help in how your SSO vendor implements them. All the vendors have copious (and almost unreadable) documentation. That is where these test tools can come in handy, because they don\u2019t require you to study the protocol syntax but offer a more human-friendly interface. To get a better idea of what lies ahead, you might read this blog from Testim, which is a general software automation testing provider. They cover the steps to set up typical SSO tests.\n\nTwo SSO vendors have details on SSO tests that are good starting places, particularly if you don\u2019t know the difference between a SAML service provider and identity provider. You don\u2019t need to be a customer to use most of these tools.\n\nYou probably should have a separate test instance for your entire web app environment so you can experiment with SSO without harming your production systems. Four vendors have put these together:\n\nIf you are using other SSO products, you will have to resort to a patchwork of tools:\n\nThird-party SSO testing tools\n\nThe problem with the SSO vendor toolset is that you have no way to automate tests across your entire applications infrastructure. This is where the third-party products come into play, such as Testim mentioned earlier. Testim is a general software testing automation vendor, of which there are dozens if not hundreds (such as Silk and Selenium, for example). While Testim doesn\u2019t offer any SSO-specific tools, you can cobble together a way to test your SSO implementation if you have specialists on staff (or outsourced) that favor a particular automation program. Other software testing companies cover SSO implementations:\n\nCanny\n\nCanny works with Azure Active Directory and OneLogin. An Okta version is in beta. It requires embedded Canny widgets to pass SSO token. Pricing starts at $50 a month.\n\nDorothy\n\nElastic\u2019s Dorothy works only with Okta and requires Elastic Security. Pricing starts at $16 a month.\n\nSSOScan\n\nSSOScan is an open-source vulnerability scanner for Facebook SSO only.\n\nWalrus\n\nWalrus works with Okta, Auth0, IBM, ForgeRock, and NetIQ. It is based on its general purpose automated testing tool. Pricing is not disclosed.\n\nMany of these testing tools come from the general testing automation space, which means these vendors can test a lot more than your SSO applications. That is both good and bad news. Good because it shows that the automation vendors are finally paying attention to resolving SSO issues. Bad because the number of SSO customers is still a small subset of each vendor\u2019s user base, which means finding a knowledgeable support person might be a challenge.\n\nActually, finding any support is a challenge. None of these vendors would respond to our queries. Another downside is that getting documentation about the SSO-related features will require some effort, too. (In Walrus\u2019s case, getting their pricing proved impossible.)\n\nThe tools offer common features:\n\nIf you use Okta\u2019s SSO module, you can try out most of these automation tools and see which one you like the best. If you use Auth0 (which Okta acquired earlier this year but is maintaining as an independent product), Ping, or something else, then you have more limited options until vendors expand their support.\n\nSecurity vulnerability testing\n\nPutting together an SSO implementation, you will likely have a few issues to ensure that a bad actor doesn\u2019t slip through your infrastructure. In an extreme example, a hacker was able to poison cryptographic tokens for escalating privilege for Active Directory.\n\nOther circumstances are more common, such as:\n\nYou might think that general-purpose vulnerability scanners can do some of these tasks, but again, not necessarily focus on the sanctity of your SSO system. Enter SSOScan, which is the only general-purpose SSO vulnerability scanner I could find, made even more limited because it will only work with Facebook\u2019s SSO logins. Because it is open source, you can examine how it is built and perhaps modify it to work with your SSO implementation. That may be more effort than it is worth if you don\u2019t use and don\u2019t care about Facebook integrations.\n\nTesting your SSO configuration can be frustrating. Some new third-party tools can help, particularly if you run Okta\u2019s SSO environment. Other SSO vendors have been slow to develop better automated methods. If you use Okta, Ping, CyberArk or Auth0 SSO, start with their tools. If you have something else, start with either OneLogin or NetIQ\u2019s code libraries. Then add your automation layer with the tool most familiar to you.