Difference between revisions of "Subprovider"

From regify WIKI
Jump to navigation Jump to search
 
(43 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. In fact, all Subprovider instances of a regify-provider, each visible with different customizing to the customers, is 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]]
  
== individual Subprovider features ==
+
== 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:
 +
 
 +
# 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
 +
# 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
 +
# 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
 +
# 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
 +
#* NO: continue
 +
# Does the customer need enhanced administration capabilities (e.g. full control over users, groups, imports, authentication etc.)?
 +
#* YES: Subprovider
 +
#* NO: continue
 +
# 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:'''
 
'''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
 
* 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 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
+
* shop-pages for premium membership for single users and group administrators
* blacklist for mail-addresses, domains and sub-domains that are rejected from registering
+
* payment options (PayPal, others)
* Terms And Conditions (German 'AGB')
+
* regibox sharing feature (on/off)
* customizable authentication form (Subprovider authentication-level can vary)
+
* blacklist for email addresses, domains and sub-domains that are prohibited from registering
* used HTTP header meta-information
+
* 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
 
* 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
 +
* language-specific sentences (limited usage recommended)
 +
* regigate connectors to limit access to Subprovider users only
  
== shared features ==
+
== Shared features ==
  
'''The following functions and settings are shared between all Subprovider (not individual):'''
+
'''The following functions and settings are inherited from the regify provider and shared between all Subproviders:'''
* maintenance-state
 
* local paths for downloads, log-files, obligatory attachments and temporary files
 
* clearing-connection is always shared between all Subproviders
 
* proxy-settings
 
* all subproviders share the same currency
 
* local time-settings (difference to UTC-0)
 
* premium-time offered as trial period
 
* number of days a registration, invitation or added mail-address is active/valid
 
* length of passwords and unlock-codes
 
* PDF settings
 
* emergency SMS settings (they all will go to the administrator of the main provider)
 
* some specific authentication-settings
 
* settings for intrusion detecting system (IDS)
 
* the definition of administrative accounts is only available to 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-administrators.
 
  
== prerequisites ==
+
All Subprovider share...
In order to manage a Subprovider, the following prerequisites are needed on the hosters side:
+
* '''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 IP address for each Subprovider
* individual domain for each Subprovider (A record in 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 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 <u>in the same database as the main provider</u>. There is <u>no physical separation</u> 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.
  
== other important information ==
+
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]]
* 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 provider-instance needs extreme effort.
 
* Subproviders are sharing their physical resources (CPU power and RAM). A heavy load of a single Subprovider leads into heavy load of all Subprovider-instances.
 
* upon restricted administration possibilities, it is strongly recommended to manage the complete administration by a employee of the main provider.
 

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