The authentication occurs at 4 levels:

a) Host/Key

Mandatory, if a server is not known (no host id in the list, wrong key associated), no request will be allowed.

From version 2.4.23, it is possible to block an existing Partner defined, without changing the configuration or deleting its definition, but by just setting the "is blocked" status (see Host web administrator screen).

b) SSL

If the SSL mode is used, the trust level of SSL could be managed:

• the SSL Server key is validated by the client (SSL default mode)
• the SSL Client key could be also validated by the server (trustuseclientauthenticate option, set to False by default, therefore not asking the client to identify itself with its own SSL key).

So the SSL allows a simple side or dual sides authentication.

c) IP

• checkaddress=True means that all IP addresses for Servers will be checked against the real IP on the network connection
• checkclientaddress=True means that all IP addresses for Clients will be checked against the real IP on the network connection

Those IP are tested to check the consistency between the declaration and the reality.

• Warning: If a non transparent proxy is present, the IP of source is replaced by the one from the proxy. In this case, the partner should be defined as proxified (see Host web administrator screen).
• Warning: For clients, except if one would like to have a very high level of security, it is in general not recommended to check the IP for the Client in order to have a simple configuration (for instance, one entry for many clients in a group)
• Warning: The authentications are stored in the database. Therefore, if several servers share the same database, they will share also those identifications.

d) In case of Shared Database

As the administrator option will probably be active for all Servers (since this field is necessary for themselved to be their own administrator, in order for instance to be able to shutdown from command line), there is an option that allows to specify a superset of roles locally, through local files, with fine grain role support. This way of doing is highly recommended in the case of database shared among several R66 servers, in order to give more flexibility and still security in the roles.

 

 

Special configuration

• Special notice for Alias: since aliases are just replaced at the very beginning of the start of any operation, there is no need to have those aliases defined in the Host database table, since they will rely on the real host definition.

 

• Note that it is possible from version 2.4.22 to specify different levels of applicable rights to a user connected to the web administration interface:

  • The default admin user (specified in the XML configuration file) has all rights (super user account)

  • It is possible to create new user accounts

    • Create "dummy" Hosts with a value of PORT < 0 (it will set automatically Address to 0.0.0.0 and isClient to True).

    • Then, you can specify the roles by either setting isAdmin to True (equivalent to super user account), or by setting the ROLES item to the values decided:

      • <roles><role><roleid>username</roleid><roleset>roles to set</roleset></role></roles>

• Roles could be:

  • TRANSFER: allow to access to CANCEL-RESTART sub menu of TRANSFERS menu

  • SYSTEM: allow to access to EXPORT sub menus of TRANSFERS menu and to all functions of SYSTEM menu

  • CONFIGADMIN: allow to access to HOSTS and RULES menu

  • By default, all other menus are allowed (LISTING and SPOOLED DIRECTORY sub menus of TRANSFERS menu, LOGON and START menus) since they do not act on the server. Note that SYSTEM menu will be limited to showing the current values (not changing them), except the Web interface language (not the server language).

  • You can combine rights, for instance by setting <roleset>TRANSFER SYSTEM</roleset> for the role, or any combination.