Kerberos authentication
Kerberos is a trusted third-party authentication service that is used to provide authentication service for client and server applications by using secret-key cryptography. The clients and servers are collectively referred to as principals. Kerberos uses a database that contains the private keys of clients and servers. The private keys are used to authenticate different clients and servers on a network. Kerberos also generates temporary session keys that are shared between a client and a server to communicate with each other. All communications between a client and server are then encrypted with the temporary session key.
The Kerberos architecture consists of the following entities and several modular services:
- Clients that need to use services provided by a server.
- Servers that provide services to clients.
- Key Distribution Center that manages the Kerberos protocol, such as generation of session keys.
The following table provides the Kerberos authentication logon workflow:
Stage | Description |
|---|---|
1 | User accesses the protected application from a client, such as a mobile device or a web browser. |
2 | Web Agent redirects the user to the Remedy Single Sign-On (Remedy SSO) console. |
3 | Remedy SSO sends to the client a 401 un-authorized request setting the header to “www-authenticate:Negotiate”. |
4 | The client ends a request for a ticket to the Key Distribution Center (KDC), which is a domain controller. |
5 | The Authentication Service of the KDC creates a ticket-granting ticket (TGT) for the client wrapped in a SPNEGO (Simple and Protected GSS API Negotiation Mechanism) Token and sends the TGT to the client. |
6 | The client then attempts to decrypt the TGT by using its password. If the client successfully decrypts the TGT, the client keeps the decrypted TGT, that indicates proof of the client's identity. |
7 | The client then sends to Remedy SSO the user access request + the Negotiate SPNEGO TGT in an Authorization: Negotiate base64(token) header and requests for a service ticket. A client can uniquely identify an instance of a service by a service principal name (SPN). A given service instance can have multiple SPNs. For example, an SPN always includes the name of the host computer on which the service instance is running, so a service instance might register an SPN for each name or alias of its host. |
8 | Remedy SSO validates the token with KDC. |
9 | KDC validates the token. |
10 | Remedy SSO creates a session for the user’s access request. |
11 | The user accesses the protected application. |
Before the Kerberos Authentication Service can use an SPN to authenticate a service, the SPN must be registered on the account object that the service instance uses to log on. A given SPN can be registered on only one account.
Related topic