Difference between revisions of "Subprovider"

From regify WIKI
Jump to navigation Jump to search
 
(4 intermediate revisions by the same user not shown)
Line 1: Line 1:
 
== The Subprovider feature ==
 
== The Subprovider feature ==
A Subprovider is a way to host multiple regify-provider instances on a single system (multi-tenant). In fact, all Subprovider instances of a regify-provider, each visible with different customizing to the customers, are running on the same hardware / virtual host.
+
A Subprovider is a way to host multiple regify-provider instances on a single system (multi-tenant). In fact, all Subprovider instances hosted by any given regify provider can be customised differently whilst running on the same hardware / virtual host.
 
[[image:Subprovider_Scheme.jpg‎|center]]
 
[[image:Subprovider_Scheme.jpg‎|center]]
  
 
== Subprovider decision ==
 
== Subprovider decision ==
  
If a regify provider starts having big customers, the decision to create a new group or even a subprovider is needed. In order to help, please follow this guide:
+
If a regify provider has customers with a large user base, then a decision needs to be made either to create a new group or a subprovider. In order to help decision making process, please follow this guide:  
  
# Does the customer need to have his data on his own infrastructure or are there security concerns if you have the data?
+
# Does the customer need to have his data on their own infrastructure or are there security concerns if you have the data?
#* YES: He needs to become a provider himself. A Subprovider runs on the same infrastructure as the main provider.
+
#* YES: Then the customer needs to become a provider in their own right. A Subprovider runs on the same infrastructure as the main provider. This means that the subprovider’s data is entirely controlled by the provider.
 
#* NO: continue
 
#* NO: continue
# Will the customer be in a different country or time zone than the main provider system?
+
# Will the customer be in a different country or time zone when compared to the main provider system?
#* YES: It is very likely that the customer will have to become a provider himself. Subproviders run the same time zone, currency and VAT than the main system.
+
#* YES: It is advisable that the customer become a provider on their own account. Subproviders run the same time zone, currency and VAT as the provider.
 
#* NO: continue
 
#* NO: continue
 
# Are there plans of the customer to become a regify provider in the future by himself?
 
# Are there plans of the customer to become a regify provider in the future by himself?
#* YES: Consider setting up a new regify provider for this customer. If complexity and costs prevent this while starting then consider having him as a group or eventually a Subprovider but be aware that migration of users will be a manual process that involves loss of transaction data and forces the users to reset their regify client. A Subprovider might be easier to migrate than a group. If the users also will use regibox, there is no way to transport and extract their data to a new system!
+
#* YES: We recommend setting up a new regify provider for this customer from the start. If complexity and costs prevent this while starting then consider having him as a group or eventually a Subprovider but be aware that the migration of users will be a manual process that involves loss of transaction data and forces the users to reset their regify client themselves. A Subprovider might be easier to migrate than a group. If the users also use regibox, there is no way to transport and extract their data to a new system!
 
#* NO: continue
 
#* NO: continue
# Does the customer need his own corporate identity (logos, templates, domain) and is willing to pay for?
+
# Does the customer want to utilize regigate for his employees/company?
 +
#* YES: Subprovider or even a real provider. This is needed to separate the accounts and secure use of regigate.
 +
#* NO: continue
 +
# Does the customer need his own corporate identity (logos, templates, domain) and is willing to pay for this?
 
#* YES: Subprovider
 
#* YES: Subprovider
 
#* NO: continue
 
#* NO: continue
# Does the customer need enhanced administration capabilities (eg full control over users, groups, imports, authentication etc)?
+
# Does the customer need enhanced administration capabilities (e.g. full control over users, groups, imports, authentication etc.)?
 
#* YES: Subprovider
 
#* YES: Subprovider
 
#* NO: continue
 
#* NO: continue
# Is the customer having more than 500 users and he is willing to pay for some separation?
+
# Does the customer have more than 500 users and is he / she willing to pay for some logical separation of data?  
#* YES: Maybe a Subprovider, but a group will be the best solution.
+
#* YES: Maybe a Subprovider, but a group will be the best solution (based on the number of users).
 
#* NO: Use groups only.
 
#* NO: Use groups only.
  
Line 33: Line 36:
 
* page-Design by using individual CSS files and images for each Subprovider
 
* page-Design by using individual CSS files and images for each Subprovider
 
* header and footer content
 
* header and footer content
* e-mail templates are completely individual (css-design, layout and text-content)
+
* e-mail templates are completely individual (CSS-design, layout and text-content)
 
* customized logo in regify-client (logo in right upper corner)
 
* customized logo in regify-client (logo in right upper corner)
 
* customized standard-template for all mails sent using standalone-client, Outlook addin, Thunderbird addin, Lotus Notes addin
 
* customized standard-template for all mails sent using standalone-client, Outlook addin, Thunderbird addin, Lotus Notes addin
* shop-pages for premium-membership of single users and group-administrators and regichat users
+
* shop-pages for premium membership for single users and group administrators
 
* payment options (PayPal, others)
 
* payment options (PayPal, others)
 
* regibox sharing feature (on/off)
 
* regibox sharing feature (on/off)
* blacklist for mail-addresses, domains and sub-domains that are rejected from registering
+
* blacklist for email addresses, domains and sub-domains that are prohibited from registering
 
* Terms and Conditions (German 'AGB')
 
* Terms and Conditions (German 'AGB')
 
* customization of authentication form (Subprovider authentication-level can vary)
 
* customization of authentication form (Subprovider authentication-level can vary)
* used HTTP header meta-information
+
* HTTP header meta-information
 
* individual configuration as community-provider or corporate-provider
 
* individual configuration as community-provider or corporate-provider
 
* selection of active and inactive portal-options for end-users
 
* selection of active and inactive portal-options for end-users
Line 66: Line 69:
 
* the length of passwords, ciphers and unlock-codes.
 
* the length of passwords, ciphers and unlock-codes.
 
* any PDF settings.
 
* any PDF settings.
* SMS settings (configuration for sending text messages, like the used mobile provider etc).
+
* SMS settings (configuration for sending text messages, like the used mobile provider etc.).
 
* some specific authentication-settings (like maximum authentication level).
 
* some specific authentication-settings (like maximum authentication level).
 
* the settings for intrusion detecting system (IDS on/off).
 
* the settings for intrusion detecting system (IDS on/off).
Line 72: Line 75:
  
 
'''Subproviders are also limited in the following functionality:'''
 
'''Subproviders are also limited in the following functionality:'''
* The definition of any administrative accounts is only available to master role administrators of the main provider.
+
* The definition of any administrative accounts is only available to the master role administrators of the main provider.
* A Subprovider is able to administrate many functions inside of his domain (user-data, groups etc.), but some functions are still only available to the main providers master role administrators.
+
* A Subprovider is able to administer many functions inside of his domain (user-data, groups etc.), but some functions are still only available to the main provider's master role administrators.
* A Subprovider is not able to see the appliance log-file entries (eg for technical issues and warnings).
+
* A Subprovider is not able to see the appliance log-file entries (e.g. for technical issues and warnings).
  
 
== Prerequisites ==
 
== Prerequisites ==
In order to manage a Subprovider, the following prerequisites are needed on the hosters side:
+
In order to manage a Subprovider, the following prerequisites are needed on the hoster's side (main regify provider location):
 
* individual IP address for each Subprovider
 
* individual IP address for each Subprovider
* individual domain for each Subprovider (A record in DNS entry and , if appropriate, a reverse-DNS entry)
+
* individual domain for each Subprovider (A record in DNS entry and, if appropriate, a reverse-DNS entry)
 
* specific SSL certificate for the desired domain
 
* specific SSL certificate for the desired domain
Sometimes we get asked about the possibility to '''host multiple subproviders on one IP address''' only. The short answer is: no, the regify provider software appliance does not support this. It is only IP based.
+
Sometimes we get asked about the possibility of '''hosting multiple subproviders on one IP address''' only. The short answer is: no, the regify provider software appliance does not support this. It is only IP based.  
  
We also get asked frequently if it is possible to '''host multiple designs on one single domain''' (corporate identities). In fact, with no different domains, the portal does not know which design to show. We need this differentiator to determine the correct design. We also do not want the user to add some additional subfolder to its domain (''regify.company.com/design1/'' or ''regify.company.com/design2/''). Most users are simply typing the main domain. This solution will cause a lot of confusion at the customers.
+
We are also often asked if it is possible to '''host multiple designs on one single domain''' (corporate identities). In fact, without a different domain, the portal does not know which design to show. We need this differentiator to determine the correct design. We also do not want the user to add some additional subfolder to its domain (regify.company.com/design1/ or regify.company.com/design2/). Most users simply type in the main domain name. Going down this avenue would cause a lot of confusion at the user community.
  
 
== Other important information ==
 
== Other important information ==
 
* A Subprovider stores his user-data and transaction information <u>in the same database as the main provider</u>. There is <u>no physical separation</u> of the data.
 
* A Subprovider stores his user-data and transaction information <u>in the same database as the main provider</u>. There is <u>no physical separation</u> of the data.
** Upon this, a later separation into a new independent provider-instance needs extreme effort.
+
** Given the above, to separate out the user data and create a new, independent provider instance needs extreme effort.
** Upon this, the main provider is able to access customer address data of his Subproviders users.
+
** It should also be noted that the main provider is able to access the subproviders's customer address data.
* Subproviders share the regibox storage. There is no way to separate the data later. '''Users with enabled regibox can not get transferred to another provider later'''.
+
* Subproviders share the regibox storage service. There is no way to separate the data later. '''Users who have enabled regibox cannot be transferred to another provider later'''.
 
* Subproviders are sharing their physical resources (CPU power and RAM). A heavy load caused by a single Subprovider will affect all other Subprovider-instances and the main provider.
 
* Subproviders are sharing their physical resources (CPU power and RAM). A heavy load caused by a single Subprovider will affect all other Subprovider-instances and the main provider.
* In order to allow emergency help to subproviders, every regify provider should have at least one account with ''master'' administration role at his Subproviders.
+
* In order to allow emergency help for subproviders, every regify provider should have at least one account with ''master'' administration role at his Subproviders.
  
If you are looking for technical information on creation of a new sub-provider, please check here: [[Setting up a new sub-provider]]
+
If you are looking for technical information on how to create a new subprovider, please check here: [[Setting up a new sub-provider|Setting up a new subprovider]]

Latest revision as of 16:00, 6 May 2022

The Subprovider feature

A Subprovider is a way to host multiple regify-provider instances on a single system (multi-tenant). In fact, all Subprovider instances hosted by any given regify provider can be customised differently whilst running on the same hardware / virtual host.

Subprovider Scheme.jpg

Subprovider decision

If a regify provider has customers with a large user base, then a decision needs to be made either to create a new group or a subprovider. In order to help decision making process, please follow this guide:

  1. Does the customer need to have his data on their own infrastructure or are there security concerns if you have the data?
    • YES: Then the customer needs to become a provider in their own right. A Subprovider runs on the same infrastructure as the main provider. This means that the subprovider’s data is entirely controlled by the provider.
    • NO: continue
  2. Will the customer be in a different country or time zone when compared to the main provider system?
    • YES: It is advisable that the customer become a provider on their own account. Subproviders run the same time zone, currency and VAT as the provider.
    • NO: continue
  3. Are there plans of the customer to become a regify provider in the future by himself?
    • YES: We recommend setting up a new regify provider for this customer from the start. If complexity and costs prevent this while starting then consider having him as a group or eventually a Subprovider but be aware that the migration of users will be a manual process that involves loss of transaction data and forces the users to reset their regify client themselves. A Subprovider might be easier to migrate than a group. If the users also use regibox, there is no way to transport and extract their data to a new system!
    • NO: continue
  4. Does the customer want to utilize regigate for his employees/company?
    • YES: Subprovider or even a real provider. This is needed to separate the accounts and secure use of regigate.
    • NO: continue
  5. Does the customer need his own corporate identity (logos, templates, domain) and is willing to pay for this?
    • YES: Subprovider
    • NO: continue
  6. Does the customer need enhanced administration capabilities (e.g. full control over users, groups, imports, authentication etc.)?
    • YES: Subprovider
    • NO: continue
  7. Does the customer have more than 500 users and is he / she willing to pay for some logical separation of data?
    • YES: Maybe a Subprovider, but a group will be the best solution (based on the number of users).
    • NO: Use groups only.

Individual Subprovider features

The following settings are customizable individual for each Subprovider:

  • internet domain name
  • SSL certificate
  • page-Design by using individual CSS files and images for each Subprovider
  • header and footer content
  • e-mail templates are completely individual (CSS-design, layout and text-content)
  • customized logo in regify-client (logo in right upper corner)
  • customized standard-template for all mails sent using standalone-client, Outlook addin, Thunderbird addin, Lotus Notes addin
  • shop-pages for premium membership for single users and group administrators
  • payment options (PayPal, others)
  • regibox sharing feature (on/off)
  • blacklist for email addresses, domains and sub-domains that are prohibited from registering
  • Terms and Conditions (German 'AGB')
  • customization of authentication form (Subprovider authentication-level can vary)
  • HTTP header meta-information
  • individual configuration as community-provider or corporate-provider
  • selection of active and inactive portal-options for end-users
  • language-specific sentences (limited usage recommended)
  • regigate connectors to limit access to Subprovider users only

Shared features

The following functions and settings are inherited from the regify provider and shared between all Subproviders:

All Subprovider share...

  • the same local database on the regify provider appliance.
  • the same assigned regibox storage and regibox quota defaults.
  • the currency and VAT settings.
  • local time and date settings (difference to UTC-0).
  • system default language settings.
  • regibox enabling/disabling by default for new users.
  • maintenance-state.
  • the clearing-connection of a system.
  • proxy-settings.
  • premium-time offered as regimail trial period.
  • the number of days a registration, invitation or added email-address is active/valid.
  • the length of passwords, ciphers and unlock-codes.
  • any PDF settings.
  • SMS settings (configuration for sending text messages, like the used mobile provider etc.).
  • some specific authentication-settings (like maximum authentication level).
  • the settings for intrusion detecting system (IDS on/off).
  • the version of the regify provider (updates are executed only by the main provider).

Subproviders are also limited in the following functionality:

  • The definition of any administrative accounts is only available to the master role administrators of the main provider.
  • A Subprovider is able to administer many functions inside of his domain (user-data, groups etc.), but some functions are still only available to the main provider's master role administrators.
  • A Subprovider is not able to see the appliance log-file entries (e.g. for technical issues and warnings).

Prerequisites

In order to manage a Subprovider, the following prerequisites are needed on the hoster's side (main regify provider location):

  • individual IP address for each Subprovider
  • individual domain for each Subprovider (A record in DNS entry and, if appropriate, a reverse-DNS entry)
  • specific SSL certificate for the desired domain

Sometimes we get asked about the possibility of hosting multiple subproviders on one IP address only. The short answer is: no, the regify provider software appliance does not support this. It is only IP based.

We are also often asked if it is possible to host multiple designs on one single domain (corporate identities). In fact, without a different domain, the portal does not know which design to show. We need this differentiator to determine the correct design. We also do not want the user to add some additional subfolder to its domain (regify.company.com/design1/ or regify.company.com/design2/). Most users simply type in the main domain name. Going down this avenue would cause a lot of confusion at the user community.

Other important information

  • A Subprovider stores his user-data and transaction information in the same database as the main provider. There is no physical separation of the data.
    • Given the above, to separate out the user data and create a new, independent provider instance needs extreme effort.
    • It should also be noted that the main provider is able to access the subproviders's customer address data.
  • Subproviders share the regibox storage service. There is no way to separate the data later. Users who have enabled regibox cannot be transferred to another provider later.
  • Subproviders are sharing their physical resources (CPU power and RAM). A heavy load caused by a single Subprovider will affect all other Subprovider-instances and the main provider.
  • In order to allow emergency help for subproviders, every regify provider should have at least one account with master administration role at his Subproviders.

If you are looking for technical information on how to create a new subprovider, please check here: Setting up a new subprovider