[IdP] IdP with SAML for multi-tenant applications and Group synchronization alongside AD
idp
Web icon
Forge component by Rui Barbosa
Application Type
Traditional Web

Hi there,

Setup: Our OutSystems Users application is already configured (and sync-ing) with Active Directory. We have configured a Keycloak instance for an SSO capability for internal and external users via SAML. We now want to use it for OutSystems, as well. We can use the SAML capability of Keycloak, but we need Multitenancy, so the built-in SAML configuration in Users application is out of question (not supported). 

Questions:

- I have seen this post:

 https://www.outsystems.com/forums/discussion/63788/anybody-know-how-to-configure-idp-with-multi-tenancy/

does anybody have a sample app where IdP works with multi-tenant applications?


- is there a possibility for automatic synchronization (setting Users to inactive in Users application, change of metadata, etc. upon change) when using the IdP? Something similar to AD Import for AD. I saw this post:

https://www.outsystems.com/forums/discussion/54639/azure-groups-not-passed-to-outsystems/

It looks like for Azure AD Groups there is, how about generic SAML?


- can/should we keep the current Active Directory configuration and mapping in the Users application alongside IdP. To me they seem compatible, has anybody tried? Could you point to sample app?

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.


Community GuidelinesBe kind and respectful, give credit to the original source of content, and search for duplicates before posting.