Currently, we had a web app that integrated with SSO through Open-Id protocol Then we got another client that had it's own SSO and need us to integrate with their SSO through SAML protocol so their employees can authenticate and use our site, then another client came with another SSO (SAML protocol).

the fast solution, we split the sites to 3 different sites and each one integrates with a different SSO yes it fast but it so bad as now we need to maintain three sites not only one.

What I am looking for to merge those site to one again and integrate with multiple SSO's. I already searched for something like that but all the solution that I found is to make different login buttons for each SSO and that will redirect and authenticate through it.

But our client refused that solution as he doesn't need anyone to know that he integrate with those clients and also need only one button for login.

Is there any solution for that?

Can I built my own SSO that rely on others SSO's with different protocols and if yes any recommendations, please?

  • Is your site deployed locally on a server of the client, or are you using a multi-tenant solution to centrally host a single site that serves multiple customers? Commented Apr 5, 2019 at 12:17
  • Deployed locally on a client's server with 3 different sites on IIS
    – Nabawoka
    Commented Apr 7, 2019 at 13:10

2 Answers 2


The auth process needs some way of telling which provider to use. But you don't need three sites. Just three urls.

Deploy the site with multiple domain name bindings and read the url the client is connecting to. Then map that to the required auth provider.

  • for clarification, you mean three domains(sites) for only authentication then redirect to one main site for all after the authentication?
    – Nabawoka
    Commented Apr 7, 2019 at 13:15
  • no, just have the one site. with multiple domain names mapped to it
    – Ewan
    Commented Apr 7, 2019 at 13:36

There are two options:

  • Some SSO providers allow you to go through them to integrate with other SSO providers. Your application would only deal with one provider and one data format. Through configuration, you would allow for exchanging information and translating with other formats. Based on rules, the SSO provider would either use authentication information that it has to determine if the user is being authenticated internally or with a different provider.
  • You can provide multiple authentication endpoints, linked to a different provider. You would have to do detection to determine which one to use. Perhaps you can prompt for a username or some other identifier that your system has and then, based on that, redirect to the appropriate SSO provider for the remainder of the authentication process.
  • Allow the user to somehow specify a provider to use. However, this appears to be unacceptable to your client. You would need to convince them that it's appropriate. It also requires your users to know what provider they must authenticate against, which may not be the best experience.
  • I think the first solution is what I looking for, I can use Identity-server to rely on others SSOs and deploy it on different URLs so after authentication will redirect to the main site, but the problem that I may face here is the IDP initiated requests .. I think it needs a POC .. Thanks :)
    – Nabawoka
    Commented Apr 7, 2019 at 13:21
  • As the product gets installed on-site, the third option could also be provided as a configuration option at install time. Commented Apr 7, 2019 at 20:00

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.