This shows you the differences between two versions of the page.
| Both sides previous revision Previous revision | |
| linux:kerberos-components [2017/09/08 11:37] – michael | linux:kerberos-components [2017/09/08 12:16] (current) – michael |
|---|
| </WRAP> | </WRAP> |
| |
| | ---- |
| |
| | <WRAP center box 100%> |
| | ===== Authentication and Authorization with Kerberos in Desktop-Based SSO ===== |
| | ''To provide authentication and authorization, Kerberos relies on a third party, the KDC, to provide authentication and authorization decisions for clients accessing servers. These decisions happen in three steps:'' |
| |
| | - ''Authentication exchange.'' When a principal first accesses the network or attempts to access a secured service without a Ticket Granting Ticket, they are challenged to authenticate against the Authentication Service with their credentials. The AS validates the user’s provided credentials against the configured identity store, and upon successful authentication, the principal is issued a TGT which is cached by the client. The TGT also contains some session information so future communication between the client and KDC is secured. |
| | - ''Ticket granting, or authorization, exchange.'' Once the principal has been issued a TGT, they may attempt to access secured services/resources. The principal sends a request to the Ticket Granting Service, passing the TGT it was issued by the KDC and requesting a Service Ticket for a specific destination. The TGS checks the TGT provided by the principal and verifies they have proper permissions to access the requested resource. If successful, the TGS issues an ST for the principal to access that specific destination. The TGS also creates session information for both the client as well as the destination server to allow for secure communication between the two. This session information is encrypted separately such that the client and server can only decrypt its own session information using long-term keys separately provided by the KDC to each, from previous transactions. The TGS then responds to the client with the ST which includes the session information for both the client and server. |
| | - ''Accessing the server.'' Now that the principal has an ST for the secured service as well as a mechanism for secure communication to that server, client may now establish a connection and attempt to access the secured resource. Client starts by passing to the destination server the ST, which also contains the server component of the session information, it received from the TGS for that destination. The server attempts to decrypt the session information passed to it by the client using it’s long-term key from the KDC. If it succeeds, the client has been successfully authenticated to the server and the server is also considered authenticated to the client. At this point, trust has been established and secured communication between the client and server may proceed. |
| |
| | </WRAP> |
| |