Share via

2.5.5.2 Negotiate Authentication Protocol

  • Article

The Negotiate Authentication Protcol use case describes how a client and a server application can negotiate to select an agreed-on common authentication protocol.

Negotiate authentication protocol

Figure 25: Negotiate authentication protocol

Goal: To select an authentication protocol that both the client computer and server computer system support.

Context of Use: A client application has to access a service on a network that requires verification of client identities, and the client and server applications are coded to use SPNEGO to negotiate a common authentication protocol.

Direct Actor: The client application or the server application, depending on how negotiation starts.

Primary Actor: The user.

Supporting Actors: The Authentication Authority (AA), the account DB, and the PKI.

Preconditions:

  • The user that started the client application is logged on to the client computer.

  • The client application, server application, and AA can communicate with each other.

  • The client and server application are configured to negotiate an authentication protocol.

Minimal Guarantees: Negotiation fails in some scenarios when a non-Windows system participates and there is no common protocol, or when the client or server application receives another reason for failure.

Success Guarantee: Both the client and the server agree on a common authentication protocol.

Trigger: The client application has to access a protected resource or a service on the server computer and: a) The client starts the negotiation phase before a request; or b) The server starts the negotiation phase in reaction to a request; or c) The server rejects access, and the client initiates the negotiation phase. The trigger depends on the implementation of the application protocol.

Main Success Scenario: The server starts the negotiation phase in reaction to a request.

  1. The server application sends the preferred authentication protocol and a list of available authentication protocols in priority order to the client application.

  2. The client application sends the preferred authentication protocol and a list of available authentication protocols in priority order to the server application.

  3. The server application agrees on a common protocol and returns the state of negotiation to the client application.

Postcondition: Both the client and server application have agreed on a common authentication protocol for further authentication process.

Extensions: None.