Difference between revisions of "Subprovider"
(21 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 | + | 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 | + | 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 | + | # Does the customer need to have his data on their own infrastructure or are there security concerns if you have the data? |
− | #* YES: | + | #* 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 | #* 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: | + | #* 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 | #* NO: continue | ||
− | # Does the customer need | + | # 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 | ||
− | # | + | # Does the customer have more than 500 users and is he / she willing to pay for some logical separation of data? |
− | #* YES: Maybe Subprovider, but group | + | #* 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 27: | 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 ( | + | * 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 | + | * shop-pages for premium membership for single users and group administrators |
* payment options (PayPal, others) | * payment options (PayPal, others) | ||
− | * blacklist for | + | * regibox sharing feature (on/off) |
+ | * 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) |
− | * | + | * 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) | * 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 | + | '''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. | * maintenance-state. | ||
− | * clearing-connection | + | * the clearing-connection of a system. |
* proxy-settings. | * proxy-settings. | ||
− | + | * premium-time offered as regimail trial period. | |
− | + | * the number of days a registration, invitation or added email-address is active/valid. | |
− | * premium-time offered as trial period. | + | * the length of passwords, ciphers and unlock-codes. |
− | * number of days a registration, invitation or added | + | * any PDF settings. |
− | * length of passwords, ciphers and unlock-codes. | + | * SMS settings (configuration for sending text messages, like the used mobile provider etc.). |
− | * PDF settings. | + | * some specific authentication-settings (like maximum authentication level). |
− | * SMS settings (for sending text messages). | + | * the settings for intrusion detecting system (IDS on/off). |
− | * some specific authentication-settings (maximum authentication level). | + | * the version of the regify provider (updates are executed only by the main provider). |
− | * settings for intrusion detecting system (IDS). | + | |
− | * the definition of administrative accounts is only available to administrators of 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 == | == Prerequisites == | ||
− | In order to manage a Subprovider, the following prerequisites are needed on the | + | 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 | + | 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 | + | 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. | ||
− | ** | + | ** 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. There is no way to separate the data later. Users | + | * 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 | + | * 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 sub-provider|Setting up a new subprovider]] |
Latest revision as of 16:00, 6 May 2022
Contents
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 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:
- 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
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