Domains and Services

As of Registration Server version 4.5.1 it is possible to reserve email domains and specify named external authentication services.

As of version 4.7 all external systems associated with the Registration Server must be registered as services. This includes: External Authentication Services, Web Portals, Shop systems and other “endpoints” that access the Registration Server API.

The information is stored globally on the TeamDrive Name Server (TDNS), and requires a Registration Server connected to TDNS in order to manage the domains and services.

Domains and Services can be managed by providers using the Admin Console. Registered domains and services belong to a Provider, however, a domain can be assigned with an account (see below).

Domains

Domains are valid internet web addresses. In an email address it is the part following the “@” sign.

The purpose of registering a domain is to reserve the domain for a particular Provider or account. Once a domain has been registered and activated only users of the associated Provider (or account) can use email address with the domain.

By reserving their own domains, companies can control the usage of company email addresses with regard to TeamDrive. Reserving a domain, ensures that users of these email address are managed by a particular Registration Server (TeamDrive is a distributed system consisting of enterprise customer and TeamDrive hosted registration servers), Provider and Account as required.

In particular, reserving a domain, prevents a company email address from being used for a personal TeamDrive account. Conversely, this ensures that companies are able to manage any TeamDrive user’s that are registered with a company email address.

Domain Activation

Providers can register new domains, however, they can only be activated by TeamDrive support. Please contact TeamDrive support to have the domains you have registered activate. TeamDrive support will only activate domains that actually belong to the requesting user. In particular, the domains of email service providers, such as “gmail.com”, “aol.com, “gmx.de”, etc. cannot be reserved, of course.

If you are an account manager, then you can request a domain be reserved from you Provider (or Registration Server manager), who will then request activation by TeamDrive.

Registration using a reserved Email Address

A reserved email address is an email address with a reserved domain.

As before, a user can be registered using the TeamDrive client, or the Admin Console. On registration an email and optional username must be provided.

A manager on the Admin Console may not create a user with a reserved email address unless they are a manager of the account or Provider that owns the domain. This ensures that users registered on the Admin Console that use a reserved email address will be associated with the correct Provider and account.

Changing the email of a user is subject to the same restriction.

When registering with a reserved email, using the TeamDrive client, users no longer need to enter a Provider code. This means that they can use the regular TeamDrive client (instead of the Enterprise TeamDrive client which requires a Provider code be entered) in order to register.

In the current release version of the TeamDrive client, on initial startup, the program requires users to enter their email address (if the user is already registered they can enter their username instead). If the client recognises the email as a reserved email it automatically directs the TeamDrive client to the required Registration Server.

Registration then proceeds as normal, and the user is added to the associated Provider and account if necessary. The license and default depot of the new user are then determined by the policies specified by the Provider and/or the account manager.

Domains and Authentication Services

Domains can be associated with an Authentication Service (see below). In this case users of the domain are required to use the specified external authentication service.

This authentication service of a domain takes priority over the external authentication service that is specified for a Provider, if any (see AUTH_SERVICE_NAME setting).

Usage of such an authentication service associated with a users email domain also does not depend on the value of the USE_AUTH_SERVICE setting of the user’s Provider.

Services

Services provide a way to manage all external systems associated with the Registration Server. There are currently 4 types of servers: “Authentication”, “Shop”, “Web Portal” and “Endpoint”.

The names of the services must be globally unique for then entire TeamDrive network. This is ensured by the fact that the details of services is stored on TDNS (the TeamDrive Name Server).

Services can be associated with domains, in the case of Authentication Services, as described above, and they can be associated with Providers using one of the following Provider settings: AUTH_SERVICE_NAME, SHOP_SERVICE_NAME and WEBPORTAL_SERVICE_NAME. These settings indicate the default service of that type used by the Provider.

Service Parameters

When you create a service you must specify the following service parameters:

  • Service name: the unique name of the service.
  • Type: the service type, see below.
  • Login URL: this is the “landing page” of the service. This parameter is required for all services.
  • Verify URL: this is required by Authentication Services (see below).
  • Authorisation: this specifies the “authorisation type” that must be used by the service when accessing the Registration Server API.
  • IP Address List: the is the IP Address of the service, or a list of IP addresses used by the service. This is required by all services that use the Registration Server API.

Service Type

A service can be one of the following types:

  • Authentication: an External Authentication Service (see below for more detais).
  • Endpoint: an unspecified service that accesses the Registration Server API.
  • Shop: the service is a Web Shop which is used to purchase TeamDrive resources such as Licenses and Depots or for purchasing additions to these resources. For example, in order to increase user or storage limits.
  • Web Portal: the service is a Web Portal. Web Portals are used for Web-based access to TeamDrive and for providing “Inbox” services.

Authentication Services

TeamDrive provides standard external authentication implementations for: LDAP, Azure, Google, LDAP, Microsoft Activate Directory, Vasco IDENTIKEY Authentication and standard Oauth 2.0 authentication.

In addition to the Login URL, all authentication services must have an associated Verify URL. See External Authentication for more details.

The Authorisation and IP Address List are not required for authentication service, because these services to not access the Registration Server API.

API Access

Services that use the Registration Server API must set the Authorisation and IP Address List parameters.

Authorisation can be one of the following: MD5 (APIChecksumSalt), MD5 (Endpoint specific key) or HMAC-SHA1 (Endpoint specific key).

MD5 (APIChecksumSalt) is the default. This is the “classic” authentication method used by all API call before Registration Server 4.7. The service uses the key value speficied by the APIChecksumSalt Registration Server setting (see APIChecksumSalt for details).

MD5 (Endpoint specific key) is an authentication method simular to MD5 (APIChecksumSalt), but instead of using the key specified by APIChecksumSalt it uses a service specific key. This key is generated automatically be the Registration Server and can be view by the administrator in the Admin Console.

HMAC-SHA1 (Endpoint specific key) is similar to MD5 (Endpoint specific key) but uses the more secure HMAC-SHA1 hashing instead of MD5 hashing. For example, in PHP you can use the hash_hmac(‘sha1’, $data, $key) function.

If you alter the Authorisation then the service will not be able access the Registration Server API until the new key is used by the service or, in the case of HMAC-SHA1 (Endpoint specific key), until the new hashing method is used.

See API Basics for more details on how to acces the Registration Server API.

Upgrading External Authentication Services

If you are running external authentication services setup prior to version 4.5.1 of the Registration Server, then “unnamed” services must be upgraded to a named authentication service. See Upgrading External Authentication Services for details.