One more time: Workarounding Multi-Sites

[hiasl]

Hi, although many issues here cover the multi-site problem, I'm still not sure how to proceed:

First of all, I read

• https://github.com/flipboxfactory/saml-sp/issues/136
• https://saml-sp.flipboxfactory.com/examples/multi-site-with-cp-login.html#solution and some more issues.

Our setup:

• We have 5 zones: prod, abn (staging before prod), qs, dev and localdev. Only the last one (localdev) has admin changes enabled and should be the only one for doing any dev work including preparing SAML.
• Additionally we have the requirement to be able to clone down databases from prod to all other zones and possibly vice versa as well.
• What's new: In all zones Craft is running now on a dedicated admin domain not equal to the frontend domains.

What I achieved:

• I could get the SAML plugin to work as long as CP and Frontend Domains were on the same domain.

What I found out or believe should be working:

• Your multi site setup suggests to create a multi-site for the CP domain. So in my localdev enviroment I could create multi-sites for each CP zone (prod, abn, qs, dev)
• Using these multi-sites I could create my service provider list with one provider for each zone in my localdev env, entity IDs would be set to the domains of the different CPs in all zones. All with the same keypair.
• This should create metadata xml with correct URLs.
• I would then copy SAML-SP's 4 database tables to all zones.
• The only problem: I do not want to transfer the multi-sites created for the CPs in my localdev env to my other envs. So I would restore my changes to the multi-sites back to the state before locally so that they do not make their way into project-config.
• That leaves the service providers pointing to a non-existing siteId in the database.

Is this a problem? Is this siteId used for anything else than resolving the CP's domains when creating the metadata xml? In #136 some ideas came up, and if I understand it correctly, they also cover my problems, right?

Thanks for you assistance.

[dsmrt]

👋 @hiasl ,

Thanks for the leg work here and clearly defining your issue. It seems clear and shows me that maybe the project config isn’t the best solution for everyone if we develop a code based solution.

The site id is to help with users defining the baseUrl for the site in the metadata.

Maybe i can find a solution for a temporary fix for your current situation and think harder on how to update the plugin for #136

Let me get back to you on the temporary solution.

[hiasl]

Hey @dsmrt from my point of view being able to put all the necessary configs and data into a config/local.saml.php file (or something like that), which is not part of my GIT repo, but is placed by my deployment process only, would be the easiest solution.

And regarding my issue: do you think my procedure would work for the moment? I will not modify/save the service provider list on my "non-allowAdminChanges" zones, so the metadata xml will not be recreated.

Thanks

[dsmrt]

I might have misunderstood.

Correct me if I'm wrong, but your trying to find a solution to the lack of multi-environment support by creating a site for each environment?

If that is the case, this would be problematic do to the relational nature of the provider linking to the site in the provider tables.

You can probably use an environmental variable for the CP site base url and one by one change that env var to the base url while creating the sp providers in the plugin.

Steps to do this:

1. Set the env var in the .env (for example $CP_SITE_URL=localhost:8080, maybe start with the local cp site url) and assign it to the site. Save the site and commit project config change to the repo.
2. Create the SP/provider for the current site (using the example host, https://localhost:8080/admin/saml-sp/metadata/new-sp)
   • make sure to set the entity id accordingly. If the base url is https://localhost:8080/ use https://localhost:8080/, if it's https://dev.mysite.com/ use https://dev.mysite.com/.
   • make sure to select the site and key pair as needed
3. repeat 1 and 2 on the next "zone"

Does that make sense?

[hiasl]

Does your solution suggest that I create 1 singular CP site instead of one for each zone? And this one site gets $CP_SITE_URL as Base URL? And it gets transferred to the other zones via project-config?

My "problem" is, that I do not want to have the CP sites in my project config / on all other zones, even if they are deactivated, because in some places users will see them and be confused. Apart from that I heard that creating multi-sites (especially useless ones) might become a multiplier on database size.

I think my real problem is, that the SSO URLs contained at the end of my service providers metadata XMLs take their base URLs from the related sites, which is not handy when you work with separate CP URLs.

[dsmrt]

Does your solution suggest that I create 1 singular CP site instead of one for each zone? ...

yes

And this one site gets $CP_SITE_URL as Base URL? ...

yes, although you'd change that variable value based on the zone, I'd assume

And it gets transferred to the other zones via project-config?

yes, the site id is saved for the provider record and I can't guarentee things will work if the site doesn't exist.

I understand your concern about the confusion and it contributing to the size of the db but a site needs to associated to the provider for the plugin to work correctly as it is today. It's also pretty handy for the majority of use cases. It makes configuring much easier than an open text field that might confuse users more than help.

As you know, I am currently evaluating the complexity of some of the multi-environment aspects of the plugin and will take your concerns into consideration.

[hiasl]

ok, thank you, I appreciate your help very very much! I will try (maybe also without transferring the CP site), and post my experiences her.

[dsmrt]

Let me know how this goes. I appreciate the insight!

[hiasl]

Thanks again Damien, with your help we found a solution that works for us.

Our environment / requirements:

• We have 5 staging zones, only the first one has admin changes allowed via config.
• Our Craft Control Panel is reached via its own domain in the non-admin zones (2-5).
• SAML is used for Control Panel login only, no Frontend logins.
• We currently only have one frontend domain per zone, which might expand in the future

Our expectations:

• We want to prepare the complete SAML Setup in this first zone and deploy it to the others
• We want to be able to transfer databases between zones while keeping SAML alive.

The problem:

• Each zone needs its own SAML service provider being prepared in advance so that databases can be swapped.
• When you prepare the service providers (SP) locally in your dev environment, the SP's metadata xml contains URLs (especially the AssertionConsumerService) which are being constructed with the frontend's (maybe multi-site) BASE_URL, which needs to be selected as "associated site" when creating the service provider in the pulldown on the right.
• Since we are using a dedicated URL for the Control Panel, this URL is not available as a frontend site and therefore can not be selected in the first place.

Solution:

• We need a multisite being configured with the Control Panel URL as Base URL, so that it can be selected as "associated site".
• We call this multisite "Control Panel" and use an environmental variable called BASE_CP_URL as BASE_URL in the settings of the site
• Next we create the service providers for each zone -- Make sure you have a key ready or create one (it can be the same for all zones) -- Next we assign the URL of the CP to the BASE_CP_URL variable in our .env file to , including https://, e.g. https://controlpanel.domain.com. For the moment, this assures that the zone's CP URL is the base URL for our "Control Panel" multisite. -- Now it's time to create the service provider: Chose the key, use the CP domain as entity ID and chose the "Control Panel" multisite as "associated site". Save it. -- You can now verify, if the created service provider's metadata XML uses the correct domain for the zone you just created.
• We repeated these steps for each zone
• Even if you do not need it, commit your "Control Panel" multisite to project config. It's cleaner that way.
• Make an SQL dump of the SAML plugins tables, which are called "keychain", "saml_provider_keychain_link", "saml_sp_provider_identity" and "saml_sp_providers".
• Now we deploy our project config to all zones
• We manually import our SAML dump into our highest zone we were currently working on. Might be production or something lower.
• Do this again for all other zones or simply dump/import the whole database of the first zone to the other zones
• Make sure, that each zone has its BASE_CP_URL configured correctly via .env or other way.
• We also created a config/saml-sp-php with the following content: 'entityId' => getenv('BASE_CP_URL'),
• This ensures that all zone automatically chose their correct entitityId from your .env File and therefor the correct service provider.