Introduction
This topic may sound a bit niche but actually has very broad applicability in web based platforms for single sign on (SSO). To start with, let’s set the context with some basics. First, single sign on – this is a technique that allows a user to navigate from one website to another website without being asked to provide credentials again. As an example, a student signs in to a university portal and then opens externally hosted services such as Canvas to work on their assignment without being asked to enter separate credentials for Canvas. In order for the SSO solution to work between two websites, some level of trust needs to be established between the two website platforms. There are two industry standard protocols available to establish this trust – Simple Assertion Markup Language (SAML) and OpenID Connect (OIDC) with SAML being the more traditional and older protocol. Establishing the trust between the two websites in order for SSO to work requires a few things – certificate being one of the key pieces for SAML based SSO.
Domain Matching
Establishing the trust between the two websites is actually not enough for SSO to work seamlessly across all modern browsers. Most of the websites use HTTP cookie for session management and modern browsers are increasingly restrictive on cookies due to security vulnerability risk. As an example, if a user navigates from www.companyA.com to www.companyB.com using SSO, in Safari and in private browsing mode of Chrome, IE Edge the SSO will fail. As companyA and companyB websites are under two separate domains, these browsers will block the session cookie of companyA to be accessible for the purposes of establishing SSO with companyB causing the failure. In order to solve this issue, the most common approach is doing some networking for domain matching which I have covered separately in the article here. By doing domain matching, when from www.companyA.com user navigates to companyB website, the URL in the browser could be something like companyB.companyA.com This domain matching solution requires some certificate work as well.
To summarize, in order to implement SAML SSO that works seamlessly across browsers, there are two separate certificate setup activities that need to happen. This often creates confusion about why we need two certificates and how they are used. The rest of the article explains the purpose of the two certificates.
Certificate to establish trust between two website platforms
Based on the examples of companyA and companyB we discussed above, during the SSO process companyA will produce a SAML assertion which will be received by companyB. companyB now needs to validate that this SAML assertion came from companyA and not from a fraudster. In order for this validation to work, as part of the setup process companyA shares a certificate with companyB. During the SSO process, companyA signs the SAML assertion with its private key. After receiving the SAML assertion, companyB uses the certificate shared by companyA to validate that the SAML assertion was signed by companyA.
Certificate for domain matching between two website platforms
Apart from addressing cookie issue by implementing domain matching (browser URL shows companyB.companyA.com instead of www.companyB.com), the domain matching approach serves couple of additional purposes as well – a) companyA is able to retain its own brand in the browser even though the content is served by companyB b) user feels comfortable that it’s a legitimate website by seeing the URL is still under the domain companyA where they originally logged in.
The additional certificate work required in this step to load companyB website under companyA brandname with a URL such as companyB.companyA.com is to prevent users from seeing a certificate error in the browser. As part of the setup process, companyB creates a certificate request file (CSR) and shares it with companyA. Then companyA creates a certificate signed by companyA’s certificate authority using the CSR file shared by companyB. As a next step, companyA shares the certificate with companyB and then companyB installs that in their internet facing infrastructure such as a reverse proxy layer or a load balancer or a web server. Without this step, the user will see a certificate error when companyB.companyA.com loads in the browser. Setting up this certificate allows the browser to see that the webpage that is being served under the domain companyA with URL companyB.companyA.com supports HTTPS and the certificate is issued by a trusted certificate authority (CA).
Conclusion
In this article we described the necessity of two certificates in order to implement a SAML SSO that works across all modern browsers. I hope this is helpful for developers and network engineers to understand the purpose of requiring two certificates in order to effectively establish SAML SSO between two websites as well as the steps that need to be followed.
References
- https://dzone.com/articles/third-party-cookies-networking-solution
- https://learn.microsoft.com/en-us/entra/identity-platform/single-sign-on-saml-protocol
- https://www.ssl.com/article/browsers-and-certificate-validation/
- https://www.digicert.com/blog/what-is-a-certificate-authority