]> git.apps.os.sepia.ceph.com Git - ceph.git/commitdiff
doc/architecture: "Edit HA Auth" 53620/head
authorZac Dover <zac.dover@proton.me>
Sat, 23 Sep 2023 02:26:18 +0000 (12:26 +1000)
committerZac Dover <zac.dover@proton.me>
Sat, 23 Sep 2023 17:53:12 +0000 (03:53 +1000)
Rewrite the explanation of how a client authenticates against a monitor.
This is a rewrite of a single paragraph, and has been set apart in its
own PR so that it can receive the maximum amount of scrutiny that the
upstream Ceph community can muster.

Co-authored-by: Anthony D'Atri <anthony.datri@gmail.com>
Signed-off-by: Zac Dover <zac.dover@proton.me>
(cherry picked from commit c71cd84ec9e579ba0913c4952570bba6082e03b5)

doc/architecture.rst

index e5c3b23568febfa8266172029b8695bd764dca3c..a9253d669788c62abd13157d846ed208c9e72137 100644 (file)
@@ -278,16 +278,16 @@ the client and the monitor share a secret key.
                 | transmit key  |
                 |               |
 
-To authenticate with the monitor, the client passes in the user name to the
-monitor, and the monitor generates a session key and encrypts it with the secret
-key associated to the user name. Then, the monitor transmits the encrypted
-ticket back to the client. The client then decrypts the payload with the shared
-secret key to retrieve the session key. The session key identifies the user for
-the current session. The client then requests a ticket on behalf of the user
-signed by the session key. The monitor generates a ticket, encrypts it with the
-user's secret key and transmits it back to the client. The client decrypts the
-ticket and uses it to sign requests to OSDs and metadata servers throughout the
-cluster.
+Here is how a client authenticates with a monitor. The client passes the user
+name to the monitor. The monitor generates a session key that is encrypted with
+the secret key associated with the ``username``. The monitor transmits the
+encrypted ticket to the client. The client uses the shared secret key to
+decrypt the payload. The session key identifies the user, and this act of
+identification will last for the duration of the session.  The client requests
+a ticket for the user, and the ticket is signed with the session key. The
+monitor generates a ticket and uses the user's secret key to encrypt it. The
+encrypted ticket is transmitted to the client. The client decrypts the ticket
+and uses it to sign requests to OSDs and to metadata servers in the cluster.
 
 .. ditaa::