Hey,
I can tell you what we have done setting up multi-tenancy and SSO. This may not be your exact solution, but perhaps it can inspire.
We have many customers (tenants) on the same production system using different SSO solutions for different tenants. Some of our components are the following:
A. The login screen has a normal login screen to support users who do not yet have SSO, but also the ability to redirect users to their appropriate SSO configuration by doing a tenant switch and sending them to a page without permission (which will force a SSO redirect).
B. We have an internal table of tenant IDs, names and email masks so we know where to send people based on their email addresses, but also generate a hashKey as a direct sign-in method so users do not have to enter their emais. See #1 under setup. So instead of going and entering their email, they have a direct link to a hashKey that knows where to send them.
This solves our first problem: Somebody coming in from the internet, and you need somehow to find out WHERE to send them when they have not yet identified themselves. With multi tenants you cannot just send them to the same place.
C. Our login mechanism will know whether to make a redirect to SSO signon depending on the tenant they're in, or whether to use built-in signon.
D. Our Users authentication settings are not touched and set to default, since it's overridden by IdP and IdP-react modules.
E. IdP have been setup with the two fields mentioned by Jessica Lee in this post: https://www.outsystems.com/forums/discussion/63788/anybody-know-how-to-configure-idp-with-multi-tenancy/
F. IdP-react is installed on all environments and acts as a bridge between IdP and does the login action for users
To setup a new user for us, we do:
1. Update our internal Tenant configuration with SSO=True and emailmask = "@acme.com", tenant id = 176 etc.
2. Create a "hashKey" randomly that we can give to the customers as a direct link, e.g.
"MyApp/Login?hashKey=gh43gj432uio432uio432bhfsd" The customer often adds this a an alias to their
environment like "https://apps.acme.com/theirapp"as a redirect to that URL. That'll handle the sign-on from there.
2. Give our global SSO url to the customer for Azure configuration (ends in "/IdP" like seen in other post - all customers use that one)
3. Have the customer create a Manifest in Azure by adding an OutSystems enterprise application (also described elsewhere), send that manifest to us.
4. Stick the manifest in IdP settings and save, make sure the configuration is on the correct tenant.
5. Go to the alias https://apps.acme.com/theirapp, login via SSO, the IdP module creates the user automatically (we do not have users before they actually visit us, nor we do we need to!), and they're logged in and created as part of the Servicecenter users like normally.
This is not meant to be a complete solution to your specific setup, but an example of how we solved a similar issue.