Configuring kerberos authentication

Edit online

Kerberos is a secure, ticket-based authentication protocol designed to provide strong network authentication for client-server applications using secret-key cryptography.

Before you begin

Note: Kerberos is a requestable feature, VDEV-196042 (Kerberos Desktop SSO via krb5). To request this feature, contact your IBM Sales representative or IBM contact and indicate your interest in enabling this capability. You can also create a support ticket with the feature number if you have the permission. IBM® Verify trial subscriptions cannot create support tickets.

You must have administrative permission to complete this task.
Log in to the IBM Verify administration console as an Administrator. For more information, see Accessing IBM Verify.

About this task

Kerberos provides three key security services: authentication, authorization, and accounting. It helps to authenticate users over an insecure network without transmitting passwords in plaintext. It allows users to prove their identity once and then access multiple services without re-entering credentials.

Advantages of using Kerberos:

Prevents password transmission over the network.
Protects against replay attacks (timestamps ensure tickets are valid for a limited time).
Enables Single sign-on hence, a scalable option for large enterprise networks.

Key components of kerberos

Key Distribution Center (KDC)
- Central trusted authority
- Contains two logical components:
  - Authentication Server (AS): Verifies user identity
  - Ticket Granting Server (TGS): Issues service tickets
Client: The user or application requesting access.
Service server: The resource the client wants to access (for example, file server, email server).

How SPNEGO Works with Kerberos

SPNEGO (Simple and Protected GSS-API Negotiation Mechanism) is a critical companion protocol that extends Kerberos functionality in heterogeneous environments.

The following describes the authentication process when a browser accesses a Kerberos-protected web application using SPNEGO:

The client requests access to Web application for a web resource.
The request is parsed through SPNEGO which checks it for the required Authorisation header. If the request doesn’t contain the header or the header is not according to GSS specifications, then a response is sent to the Browser for next supported authentication algorithm. The process continues till the required token is received automatically.
The browser now requests for Kerberos service ticket from TGS in KDC.
The TGS internally connects to Active Directory users and returns a time based ticket to the browser.
The TGS generated ticket is now sent in the Authorisation header and parsed through SPNEGO. SPNEGO obtains the user information and calls GSS API.
The API loads the Kerberos configuration (KRB5 Config) and validates the ticket. If validation is passed, request is sent to the web application resource.
The web application resource processes the request and the response is sent to the browser.

Procedure

Log in as an administrator on Verify. Navigate to the profile icon and click Switch to admin.
Select Security > Kerberos.
Upload the .keytab file. See Configuring the keytab file for more details.
A keytab file (key table file) is a file that stores Kerberos principals and their associated encrypted keys. It allows services and applications to authenticate to Kerberos automatically without requiring interactive password entry or storing passwords in plaintext.
The file contents can include Kerberos principals, Encryption keys, Key version numbers (KVNO) and Encryption types.
Enter the Service principal name (SPN) in the provided field. You can add multiple SPNs. See Configuring Service Principal Name for more details.
A Service Principal Name (SPN) is a unique identifier for a service instance in a Kerberos environment. It's essentially the address that clients use to request authentication tickets for a specific service running on a specific server. It uniquely identify services and enable clients to request the correct service tickets from the KDC.
Note:
- One account can have multiple SPNs.
- Each SPN can only be registered to one account.
- Duplicate SPNs cause authentication failures.
Select the supported Identity provider from the dropdown menu.

Note: The system lists every identity provider other than IBMid and social identities.
Enable just-in-time JIT provisioning to create or update a user account at the service provider on the first time that a user authenticates with IBM Verify. Use JIT provisioning for cases where the service provider does not require the user identity information to be created or known to it before the user attempts to access the service provider.
User mapping rule: You can use the CELx editor to define an expression to transform the kerberos userPrincipalName during user provisioning by using the format: {"p": {"username": [$expression$]}} where $expression represents your custom expression.
For example,
```
{"p": {"username": [requestContext.userPrincipalName[0].split('@')[0]]}}
```
CEL Evaluation Rules
- The CEL expression must return JSON . If any other data type is returned, the request fails
- If the CEL expression is invalid or incorrect, the evaluation fails.
Note:
- By default, if the Identity provider is selected as Cloud directory and the CEL expression does not explicitly modify the source, then the selected Identity provider is considered.
- If the Identity provider is explicitly set through CEL, then it is considered over the selected Identity provider.
- The same behaviour applies to other identity sources, such as SAML or OIDC.
See Attribute functions for more details.
Make sure that the rule works.
1. Select Show.
  A sample JSON editor shows the userPrincipalName.
2. Select Run test.
3. Verify that a correct value is returned in the Results section.
  For more information about writing custom rules, see Attribute functions.
4. Select Save.