During the creation of a new setup, the user usually tries to test the site without making it accessible to the public, which creates a need for multiple environments.
The standard go-to technique would be the creation of three environments i.e. Development, Testing/Staging and Production.
Note: To enable this feature you need to have the different licenses where you want to activate the plugin.
Each environment has its own functionality:
Development environment: It is essentially where the developers write their code, make code updates, and where all their commits and branches exist. It does not affect what the end-user sees & allows developers to try out new features and updates before pushing them forward to deployment.
Testing/Staging environment: It is where any major issues must have been already addressed and resolved before hitting production (also known as a pre-production environment). The product version in this environment should be as close to the real thing as possible, and should nearly mirror what the end users would see in the production environment.
Production environment: It is where the software or products are made live for use of the intended users. Once something is in the production environment, any and all bugs need to have already been fixed and the product or update must work perfectly.
Flow of Migration
Note: During Standard Migration, you can also migrate files from your database to the final environment from your initial environment.
Migration issues and their solution provided by us
In multiple environments, migration from one environment to another is a pretty common process, but usually, this process breaks the flow of information, especially in SSO.
When a user migrates their configuration from one site to another, SSO breaks due to the following reasons:
When the user migrates from one environment to another, the previous configuration is overwritten upon migration breaking the SSO for that specific configuration. During migration, the SP metadata also changes while switching environments that resulting in the breaking of SSO.
For example, if a user has configured Okta as IDP on the development site, they would not be able to retain Okta’s configuration upon migration to the testing site.
In this case, the configuration would need to be done again.
Solution: You can enable the "Manage Multiple Environment" feature in the plugin. This feature will allow you to save the configuration of multiple environments in the same environment. After migration, SSO configurations will be present in all the environments and the miniOrange SAML 2.0 SSO plugin will pick the SSO configuration based on the FQDN of the site.
The steps for configuration for the same are given in the guide below. This function also allows the generation of SP Metadata in advance for the other environments which are used to configure the SP Metadata in the IDP.
Another issue that results in SSO breaking is the usage of the same license for different environments.
This is because each license is linked to the specified domain. If the user tries to use the same license key for multiple environments a conflict arises which results in the breaking of SSO.
This gives the need for the purchase of separate licenses for different environments.
Solution: Multiple Environments require separate licenses where each environment has its own license key to avoid conflict between two or more environments. If you have a license key for each environment, then with the "Enterprise Plan or All-inclusive Plan” license migration will be seamless.
You will only need to provide license details on the development instance and after each push to the next environment, the license will be automatically picked by the plugin.
Guide to Configure Multiple Environments in miniOrange SAML 2.0 SSO plugin (This is an Enterprise feature)
Step 1: Configure SAML SSO plugin with IDP Metadata
In the miniOrange WordPress SAML SP SSO plugin, navigate to SP (Service Provider) Metadata tab. Here, you can find the SP Metadata such as SP Entity ID and ACS (AssertionConsumerService) URL which are required to configure your IDP (Identity Provider).
After activating the Enterprise version of the SAML 2.0 SSO plugin, go to the plugin and Enable Multiple Environments.
For adding a new Environment refer to the following steps:
Enter the Environment Name you want to add, for example: Staging.
Navigate to General settings from the sidebar of your Staging WordPress Site.
Copy the site address and paste it in the Site URL for the Environment.
Similarly enter the Site URL of any other environments you have, and click on Save.
This will add new buttons in the Service Provider tab, click on the respective button and add your configuration.
After migrating, the plugin will automatically fetch the correct configuration for your current environment.
Go to the initial environment from where you want to migrate the data and configure your SP with the desired IDP.
Go to the Service Provider Setup tab and click on Upload IDP Metadata. You can either Upload your Metadata or Fetch the Metadata by providing the Metadata URL.
Click on Save and Test configuration to check your SSO configuration.
Note: The Test Configuration works only for the current environment which has been configured by you with the IDP.
Change the environment and follow the steps again to set up the SAML 2.0 plugin in that environment.
Step 2: Clone the database in the first environment into the second environment
After cloning the database in the first environment, the second environment retains the IDP configuration of the first environment.
Our WordPress SAML SSO Plugin supports integrations with a number of addons to extend the functionality of your site.
If you have any custom requirement, please contact us at firstname.lastname@example.org and we will help you achieve your use case.
If you dont hear from us within 24 hours, please feel free to send a follow up email to email@example.com
This privacy statement applies to miniorange websites describing how we handle the personal
When you visit any website, it may store or retrieve the information on your browser, mostly in the
form of the cookies. This information might be about you, your preferences or your device and is
mostly used to make the site work as you expect it to. The information does not directly identify
you, but it can give you a more personalized web experience.
Click on the category headings to check how we handle the cookies.
Strictly Necessary Cookies
Necessary cookies help make a website fully usable by enabling the basic functions like site
navigation, logging in, filling forms, etc. The cookies used for the functionality do not store any
personal identifiable information. However, some parts of the website will not work properly without
These cookies only collect aggregated information about the traffic of the website including -
visitors, sources, page clicks and views, etc. This allows us to know more about our most and least
popular pages along with users' interaction on the actionable elements and hence letting us improve
the performance of our website as well as our services.