Difference between revisions of "Subprovider"
Jump to navigation
Jump to search
| Line 12: | Line 12: | ||
* 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 of single users and group-administrators | ||
| − | * blacklist for | + | * blacklist for mail-addresses, domains and sub-domains that are rejected from registering |
| − | * Terms And Conditions ( | + | * Terms And Conditions (German 'AGB') |
| − | * customizable authentication form ( | + | * customizable authentication form (Subprovider authentication-level can vary) |
| − | * used | + | * used 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 24: | Line 24: | ||
* language-specific sentences | * language-specific sentences | ||
* maintenance-state | * maintenance-state | ||
| − | * local | + | * local paths for downloads, log-files, obligatory attachments and temporary files |
| − | * clearing-connection is | + | * clearing-connection is always shared between all Subproviders |
* proxy-settings | * proxy-settings | ||
* local time-settings (difference to UTC-0) | * local time-settings (difference to UTC-0) | ||
* premium-time offered as trial period | * premium-time offered as trial period | ||
| − | * number of days a registration, invitation or added | + | * number of days a registration, invitation or added mail-address is active/valid |
* length of passwords and unlock-codes | * length of passwords and unlock-codes | ||
* PDF settings | * PDF settings | ||
| Line 36: | Line 36: | ||
* settings for intrusion detecting system (IDS) | * settings for intrusion detecting system (IDS) | ||
* the definition of administrative accounts is only available to administrators of the main provider | * 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 ( | + | * 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 == | == prerequisites == | ||
| Line 45: | Line 45: | ||
== other important information == | == other important information == | ||
| − | * a Subprovider stores his | + | * 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 | + | * 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. | * upon restricted administration possibilities, it is strongly recommended to manage the complete administration by a employee of the main provider. | ||
== when to choose Subprovider or not == | == when to choose Subprovider or not == | ||
| − | A | + | A Subprovider is an option for customers that are planning to provide the regify service to a limited number of accounts (eg for a maximum of 2000 users). Furthermore, a Subprovider makes only sense if the number of accounts exceeds the limit of a few hundred accounts. |
If you plan to grow the number of user-accounts up to a few thousands or more, you definitely should host your own regify-provider. | If you plan to grow the number of user-accounts up to a few thousands or more, you definitely should host your own regify-provider. | ||
Revision as of 14:39, 18 March 2011
Contents
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.
The following settings are customizable individual for each Subprovider:
- page-Design by using individual CSS files and images for each Subprovider
- header and footer content
- e-mail templates are completely individual (css-design 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 of single users and group-administrators
- blacklist for mail-addresses, domains and sub-domains that are rejected from registering
- Terms And Conditions (German 'AGB')
- customizable authentication form (Subprovider authentication-level can vary)
- used HTTP header meta-information
- individual configuration as community-provider or corporate-provider
- selection of active and inactive portal-options for end-users
The following functions and settings are shared between all Subprovider (not individual):
- language-specific sentences
- maintenance-state
- local paths for downloads, log-files, obligatory attachments and temporary files
- clearing-connection is always shared between all Subproviders
- proxy-settings
- 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
In order to manage a Subprovider, the following prerequisites are needed on the hosters side:
- individual IP address for each Subprovider
- individual domain for each Subprovider (A record in DNS entry)
- specific SSL certificate for the desired domain
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. 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.
when to choose Subprovider or not
A Subprovider is an option for customers that are planning to provide the regify service to a limited number of accounts (eg for a maximum of 2000 users). Furthermore, a Subprovider makes only sense if the number of accounts exceeds the limit of a few hundred accounts.
If you plan to grow the number of user-accounts up to a few thousands or more, you definitely should host your own regify-provider.
If you plan to process very high secure data, it may be a good idea to protect your users by hosting your own regify-provider.
If you need full access to the provider data by using the Provider-SDK, you are better hosting your own instance.
