GN4 does not handle directly the login and authentication of users to the workstation – this task is performed by some external directory and/or security system (e.g. Active Directory and IIS).

Once the user has logged in and has been authenticated by this third-party system he is matched to a user object inside the GN4 database.

This matching is done simply by logon name: the string that uniquely identifies the user in the external security system must be the same of the corresponding user object in the database. E.g. when using Active Directory, the string identifying a user could be something like Acme\jsmith (where Acme is the domain and jsmith is the logon name – probably of a John or Jane or Joe Smith). This will match a user object in the GN4 database that has name Acme\jsmith (the name is the key for user objects, so there is only one user object matching the name).

If there is no GN4 user object matching the logon identification string GN4 can do one of the following:

•Refuse the user outright – i.e. deny access to the system (strict mode);

•Map the user to one of two default user object called Guest or Administrator (non-strict mode).

In non-strict mode, users that are identified by the external security system as administrators are mapped to Administrator and all the other users are mapped to Guest.

The use of the strict or non-strict login method depends on the client and/or the configuration used to connect to GN4. Typically Web clients use non-strict mode and Windows client use the strict mode.

Web services login and authentication

Each Web services call is an HTTP POST or GET to a Web page hosted on a IIS Web server. As such each and every request is always authenticated by IIS based on its settings. If IIS is set to 'Anonymous Authentication' there would be no authentication, is IIS is set to 'Windows Authentication' or 'Basic' or 'Digest' there will be authentication against valid Windows users (either local to the IIS machine or domain/Active Directory users of the IIS machine domain).

Once the request has been authenticated by IIS, the GN4 server code processes it - and to do it needs a 'ServerLogin' object corresponding to a specific GN4 user:

•If the request contains a 'ticket' (GUID) identifying a previously created ServerLogin, the server code use it to retrieve that ServerLogin object.

•If the request does not contain a 'ticket', the server code maps the Windows user to a GN4 one and creates a new corresponding ServerLogin object.

The Windows user is the one that IIS authenticated, or if IIS is set to Anonymous Authentication, it will be the user specified in Anonymous user identity in the IIS settings.

The mapping from Windows users to GN4 ones is done as follows:

•If the complete Windows user name ('domain\name' or 'machine\name') match exactly (case-insensitive) the name of GN4 users, this is the user that is used.

•If there is no matching name and the Windows user is an administrator, the GN4 built-in Administrator user is used.

•If there is no matching name and the Windows user is not an administrator, the GN4 built-in Guest user is used

When a client (cmd4, shell4, mashup web site) connects to a GN4 server, it needs to pass credentials (user name, domain, password) for the IIS authentication. This can be either the credential of the Windows users running the client application, or 'ad-hoc' ones. The Windows users ones are the normal choice when the client and the GN4 server are part of the same domain or active directory - and so local Windows users are recognized by the server. 'Ad-hoc' credentials are needed when the client runs on a separate domain/network of the server (e.g. if the server is on a remote hosted machine), and so the local Windows user cannot be recognized remotely.

The (optional) user name / domain / password stored in the UserConfig.xml server connection configuration are these 'ad-hoc' credentials - they are used for IIS authentication and they must be Windows users/domain/password valid on the GN4 server machine.

Ditto for the user name / domain / password that can be specified on a cmd4 command-line with the -srvusername, -srvdomain, -srvpassword options.

Ditto for the userName, password and domain parameters of the ClentLogin() constructor used of the Client.ClientLogin class used for SOAP connections,

Ditto for the BasicCredential property of the GNClient.Rest class used for REST connection (here a constructor with the same parameters as the ClientLogin one would be probably a good idea).

It must be always possible to specify 'ad-hoc' credentials for IIS authentication for any client - because the Windows user ones would not work in all cases.

In same cases it might be useful - or needed - to connect to a GN4 server using a GN4 users that do NOT correspond to the Windows users authenticated by IIS. For example if IIS is using anonymous authentication, or if a remote client is connecting using fixed 'ad-hoc' credentials the GN4 user would always be the same.

This is possible when using the REST Web service using the do.ashx?cmd=login call, that accepts a GN4 user name and password, authenticates them against the GN4 database, create a new corresponding ServerLogin object and return its corresponding ticket - to be used in following calls.

This is currently NOT possible when using the SOAP Web service - a new SOAP call would be needed.

Note again that the user name and password passed to do.ashx?cmd=login are checked against the GN4 database, they are not IIS / Windows user name and password and so have nothing to do with the content of UserConfig.xml or the parameters passed to the Client.ClientLogin() constructor (and vice-versa).

The same do.ashx?cmd=login function (and eventually a corresponding SOAP one) can be used to create a login system in a mashup Web site that uses the GN4 user list - similar to the GN4 Web interface form authentication. Note that using the IIS Wndows authentication in such a case would make not much sense, because tipically the GN4 IIS server and the mashup Web sites will be in different domains / networks with no shared users and adding/maintaining Windows user to manipulate Web site logins is not ideal.