Keycloak: Use a definition list instead of a (broken) unordered list

docs/keycloak/index.rst

@@ -23,24 +23,26 @@ https://auth.softwareheritage.org/auth/.
 Introduction
 ------------
 
-Keycloak defines three important concepts to know about: **Realm**,
-**Clients** and **Roles**.
-
-* **realm**: It manages a set of users, credentials, roles, and groups. A user belongs
-to and logs into a realm. Realms are isolated from one another and can only manage and
-authenticate the users that they control.
-
-* **Client**: Entities that can request Keycloak to authenticate a user. Most often,
-clients are applications and services that want to use Keycloak to secure themselves and
-provide a single sign-on solution. Clients can also be entities that just want to
-request identity information or an access token so that they can securely invoke other
-services on the network that are secured by Keycloak.
-
-* **Role**: It identifies a type or category of users. Applications (e.g. webapp,
-deposit) often assign access and permissions to specific roles rather than individual
-users as dealing with users can be too fine grained and hard to manage. There is a
-global namespace for roles and each client also has its own dedicated namespace where
-roles can be defined.
+Keycloak defines three important concepts to know about:
+
+Realm
+  It manages a set of users, credentials, roles, and groups. A user belongs
+  to and logs into a realm. Realms are isolated from one another and can only manage and
+  authenticate the users that they control.
+
+Client
+  Entities that can request Keycloak to authenticate a user. Most often,
+  clients are applications and services that want to use Keycloak to secure themselves and
+  provide a single sign-on solution. Clients can also be entities that just want to
+  request identity information or an access token so that they can securely invoke other
+  services on the network that are secured by Keycloak.
+
+Role
+  It identifies a type or category of users. Applications (e.g. webapp,
+  deposit) often assign access and permissions to specific roles rather than individual
+  users as dealing with users can be too fine grained and hard to manage. There is a
+  global namespace for roles and each client also has its own dedicated namespace where
+  roles can be defined.
 
 .. _software_heritage_realms: