Authentication
Authentication |
|
Multi-tier client/server applications present a special situation for the Kerberos protocol. In this kind of application, a client might connect to a server that must connect to a second server on the back end. For this to happen, the first server must have a session ticket to the second server. Ideally, this session ticket should limit the first server's access on the second server to what the client is authorized to do, rather than what the server is authorized to do.
The Kerberos protocol deals with this situation through a mechanism known as delegation of authentication. Essentially, the client delegates authentication to a server by telling the KDC that the server is authorized to represent the client.
Delegation can be done in two ways. One way is for the client to get a session ticket for the back-end server and give it to the front-end server. Tickets obtained in this way — by a client for a proxy — are called proxy tickets. The difficulty with using proxy tickets is that the client must know the name of the back-end server. This difficulty is overcome by the second method of delegation, which allows the client to give the front-end server a TGT that the front-end server can use to request session tickets for the back-end server as needed. Session tickets obtained in this way — with credentials forwarded by a client — are called forwarded tickets. Whether the KDC allows clients to obtain proxy tickets or forwardable TGTs is determined by the Kerberos policy set by an administrator for the domain.
When the KDC issues a TGT to a client, it checks the Kerberos policy for the domain to see if proxy tickets are allowed. If they are allowed, the KDC sets the PROXIABLE flag in the TGT that the KDC issues to the client.
The client obtains a proxy ticket by presenting a TGT to the ticket-granting service and asking for a session ticket to the back-end server. The client's request includes a flag that signals that it wants a proxy ticket; the request also includes the name of the server that will represent the client. When the KDC receives the client's request, it creates a session ticket for the back-end server, sets the PROXY flag in the session ticket, and sends the ticket back to the client. The client then sends the session ticket to the front-end server, which uses it for access to the back-end server.
If a client wants to delegate the task of obtaining session tickets for a back-end server to a front-end server, it must ask the KDC for a forwardable TGT. It does this through an AS Exchange by indicating to the KDC the name of the server that will act on the client's behalf. If Kerberos policy permits forwarding, the KDC creates a TGT for the front-end server to use in the client's name, sets the FORWARDABLE flag in the TGT, and sends the ticket back to the client. The client then forwards the TGT to the front-end server.
When the front-end server requests a session ticket to the back-end server, it presents the client's TGT to the KDC. When the KDC issues a session ticket for the back-end server, it sees the FORWARDABLE flag in the TGT, sets the FORWARDED flag in the session ticket for the requested server, and returns the session ticket to the front-end server. The option of setting the FORWARDED flag in a session ticket provides an added level of security because it permits administrators to configure individual servers to reject session tickets that have been forwarded.