Kerberos

Iotellect Server users can be authenticated through a Kerberos Key Distribution Center using the Kerberos Authentication plugin. The Kerberos authentication mechanism is implemented using JAAS (Java Authentication and Authorization Service) and GSS-API (Generic Security Services Application Program Interface) and supports Kerberos V5.

A one-way authentication scheme is used, meaning that the Iotellect client proves its identity to the Iotellect server but the server does not prove its identity to the client. Furthermore, Kerberos is used only for authentication. Once a connection between the Iotellect client and the Iotellect server is established and authentication is complete, a standard Iotellect connection is used. Kerberos session keys are not used in message exchanges after authentication.

User permissions for successfully authenticated users will be assigned according to their user account role in Iotellect Server.

• The Kerberos Key Distribution Center (KDC) domain name must be accessible from both Iotellect client and Iotellect server.

• A service principal representing Iotellect server must be added to an appropriate realm on the KDC.

• All user principals must be added to the same realm on the KDC as the service principal.

• The KDC must have the Pre-Authentication feature enabled.

• The underlying operating system must support a ticket cache.

The Kerberos Authentication plugin requires the following fields to be configured:

• Username Mapping. Mapping between Iotellect Server users and Kerberos users principle names. If a registered Kerberos user principle tries to login and no corresponding Iotellect Server user is found in the mapping table, an exception is thrown.

• Service Principal Name. The unique identifier of the service instance which will be used to authenticate users.

• Password. The service principal password.

• Realm. The domain over which the authentication server has the authority to authenticate.

• KDC. Domain of the key distribution center.

• Number of Connection attempts. Maximum number of attempts to connect to the KDC.

• Waiting time. Indicates the wait time between connection attempts to the KDC.

If no Service Principal Password is provided (the Password field is left null), the operating system’s Ticket Cache will be used to look for an initialized Kerberos principal. It is very important to make sure that the only ticket in the ticket cache is the one belonging to the service principal.

Once the Kerberos authentication plugin has been configured, choose "Kerberos Authentication" in the global server configuration property external authentication.

In order to launch the Iotellect client in Kerberos mode the below listed command-line parameters are used. Note that the values entered for the parameters must exactly match the values indicated in the Kerberos plugin on Iotellect Server.

An example command-line launch of the Iotellect client into Kerberos mode would appear as follows:

~# bash client -kerberos -realm EXAMPLE.COM -kdc kdc.example.com -servicePrincipal aggserver

When  Iotellect client is started in Kerberos mode, the authentication dialog gives the user the option to authenticate via SSO or by providing their Kerberos principle user name and password. The following fields are displayed:

• IP address. Address of the target Iotellect server with which the client is attempting to connect.

• Port. Port of the target Iotellect server with which the client is attempting to connect.

• SSO. When selected, the authentication mechanism attempts to receive a Ticket Granting Ticket (TGT) from the Ticket Cache of the underlying operating system without requiring a username and password.

• Username. Kerberos principle username. Used only in the case where SSO is not selected.

• Password. Password corresponding to the Kerberos principle username. Used only in the case where SSO is not selected.

If the SSO flag is unchecked, the underlying authentication mechanism connects to the KDC to preform a Kerberos Pre-Authentication procedure and acquire a Ticket Granting Ticket (TGT).

Once the client obtains a Ticket Granting Ticket (TGT), it is then used to obtain a service ticket for the target server (defined by the "-servicePrincipal" command line parameter). The service ticket is encrypted with the server's long-term secret key and is encapsulated as part of an AP-REQ message. A token containing this AP-REQ message is then passed as a parameter to the authenticate function of KerberosAuthPlugin. Only an authorized Kerberos user can obtain such a token from the KDC.

The Service Principal Name and Password are used upon the plugin’s initialization to acquire the Server's long-term secret key from the KDC (Kerberos Pre-Authentication is used). This key is then used to decrypt the service ticket that is part of the AP-REQ message sent by Iotellect client. If the decryption is successful and the checksums match, the authentication is considered successful.

When a Client connection to the Server is established, it will not be terminated even if the corresponding Kerberos token expires. Moreover, when the “Refresh” button is clicked on the corresponding Server connection, a new token will be automatically acquired (both on the Client side and on the Server side) if the current token is expired.

Was this page helpful?

Tell us more

Send

Thank you!