Difference between revisions of "Subprovider"

From regify WIKI
Jump to navigation Jump to search
Line 20: Line 20:
 
* 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)
 +
 +
== Subprovider decision ==
 +
 +
If a regify provider is having big customers, the decision to create a new group or even a subprovider is needed. In order to help, please follow this guide:
 +
 +
# Does the user need his own corporate identity (logos, templates, domain) and is willing to pay for?
 +
#* YES: Subprovider
 +
#* NO: continue
 +
# Does the customer want to take over the users to his own provider in the future?
 +
#* NO: continue
 +
#* YES: Subprovider is no good choice as the data is all in one database.
 +
# Is the customer having more than 500 users?
 +
#* YES: Maybe Subprovider
 +
#* NO: Use groups only.
  
 
== Shared features ==
 
== Shared features ==

Revision as of 15:29, 6 March 2013

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.

Subprovider Scheme.jpg

Individual Subprovider features

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
  • payment options (PayPal, others)
  • 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
  • language-specific sentences (limited usage recommended)

Subprovider decision

If a regify provider is having big customers, the decision to create a new group or even a subprovider is needed. In order to help, please follow this guide:

  1. Does the user need his own corporate identity (logos, templates, domain) and is willing to pay for?
    • YES: Subprovider
    • NO: continue
  2. Does the customer want to take over the users to his own provider in the future?
    • NO: continue
    • YES: Subprovider is no good choice as the data is all in one database.
  3. Is the customer having more than 500 users?
    • YES: Maybe Subprovider
    • NO: Use groups only.

Shared features

The following functions and settings are shared between all Subprovider (not individual):

  • 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
  • SMS settings
  • some specific authentication-settings (maximum authentication level)
  • 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 and , if appropriate, a reverse-DNS entry)
  • 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.

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.

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 independent provider-instance needs extreme effort.
    • Upon this, the main provider is logically having access to the customer data of his Subproviders.
  • 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.
  • In order to allow emergency help to subproviders, every regify provider should have at least one account with master administration role at his Subproviders.