Single Sign On (SSO) on Windows

4D Server allows you to implement SSO (Single Sign On) capabilities in your client-server solutions on Windows.

Implementing SSO in your 4D solutions will allow users to access the 4D application on Windows without needing to reenter their password when they are already logged into the Windows domain of their company (using Active Directory). Behind the scenes, the 4D Server application delegates the authentication to Active Directory and gets the Windows session login, which you can use to log the 4D user into the database by means of your standard login method.

Note: For an overview of 4D's authentication and other security features, see the 4D Security guide.

The SSO feature is available:

• with 4D Server applications on Windows (4D single-user applications do not support SSO)
• with the ServerNet network layer enabled. For more information, please refer to the New ServerNet Network Layer (compatibility) paragraph.

By default, the SSO feature is not enabled in 4D Server. To benefit from this feature, you need to set the Authentication of user with domain server option on the Client-Server/Network options page of the Database Settings dialog box of 4D Server:

When you check this option, 4D transparently connects to the Active directory of the Windows domain server and gets the available authentication tokens.

This option offers standard authentication through the NTLM protocol. 4D supports both NTLM and Kerberos protocols. The protocol used is automatically selected by 4D depending on the current configuration (see Requirements for SSO). If you want to use the Kerberos protocol, you need to fill in the additional SPN field as well (see below). 

If you want to use Kerberos as your authentication protocol, you also need to fill in the Service Principal Name option on the Client-server/Network options page of the Database Settings dialog box:

This option declares the SPN as set in the Active Directory configuration. A service principal name is a unique identifier of a service instance. SPNs are used by Kerberos authentication to associate a service instance with a service logon account. This allows a client application to request that the service authenticates an account even if the client does not have the account name. For more information, please refer to the SPN page on the MSDN web site.

The SPN identifier must respect this pattern:

• "ServiceName/FQDN_user" if the SPN is a computer attribute
• "ServiceName/FQDN_computer" if the SPN is a user attribute

Where:

• ServiceName is the name of the service which the client wants to authenticate.
• The Fully Qualified Domain Name (FQDN) is a domain name that specifies its exact location in the tree hierarchy of the Active Directory for both computers and users.

In 4D databases, the SPN can be set:

• in the database structure settings, for use with 4D Server.
• or in the user settings (settings.4DSettings file stored in the database's Preferences folder) for deployment needs.

When SSO features are enabled (see above), you can rely on user authentication based on Windows session credentials to open a user session on 4D Server.

Keep in mind that the SSO feature only provides you with an authenticated login; it is up to you to pass this login to your standard 4D login method. When a 4D remote application tries to connect to the server, you have to call the 4D Current client authentication command, which will return the user login, as defined in the Active Directory. You can then pass this login to your own identification system (using the built-in user and groups, the LDAP commands, or any custom mechanism) to open the appropriate session for the remote user in your 4D application. 

This principle is illustrated in the following graphic:

The Current client authentication command must be called in the On Server Open Connection Database Method, which is called each time a remote 4D opens a new connection to the 4D Server database. If authentication fails, you can return a non-null value in $0 to reject the connection.

To call the Current client authentication command, use the following syntax:

Where:

• login is the ID used by the client to log into the Active Directory (text value). You need to use this value to identify the user within your database.
  If the user is not correcty authenticated, an empty string is returned and no error is returned.
• domain and protocol are optional text parameters. They are filled by the command and allow you to accept or reject connections depending on these values:
  
  • domain is the Active Directory domain name
  • protocol is the name of the protocol used by Windows to authenticate the user.

For more information on this command, please refer to the Current client authentication command description.

4D Server handles various SSO configurations, depending on the current architecture and settings. The protocol used for authentication (NTLM or Kerberos) as well as information returned by the Current client authentication command depend on the actual configuration, if all requirements are respected (see below). The protocol actually used for authentication is returned in the protocol parameter of the Current client authentication command.

The following table provides the requirements for using NTLM or Kerberos authentication:

(*) The following specific configuration is supported: the 4D remote user is a local account on a machine that belongs to the same AD as 4D Server. In this case, dethe domain parameter is filled with the 4D Server machine name. Note that the support depends on actual user settings: if not available, empty strings are returned.

(**) If all Kerberos requirements are respected but the Current client authentication command returns "NTLM" in protocol, this means that you are facing one of the following situations:

• The SPN syntax is not valid; in other words, it does not respect the constraints imposed by Microsoft.
• Or, the SPN has duplicates in the AD. This issue needs to be fixed by the AD administrator.

Note: A valid syntax does not mean that the SPN declaration itself is correct; more specifically, if the SPN does not exist in the AD, Current client authentication returns empty strings.