Keycloak servers as an OpenID Connect provider, facilitating user authentication for client applications. In simpler terms, keycloak administers users and provides them with JWTs containing various claims, that can be used by applications downstream. Alternatively keycloak supports OAuth2 and SAML. Keycloak is needed when multiple microservices require a single source of truth regarding user authentication. Keycloak supports centralized and distributed creation of users and groups, role/permission assignment and much more.
Essentially namespaces - isolated environments.
Applications or services that require authentication from keycloak. Each one should be configured in accordance with the OpenID Connect (redirect URIs, etc).
Individual accounts that can authenticate with keycloak. Can be organized into groups.
Used for bulk role/permission assignments.
Free-form permissions through roles and attributes assigned to users and groups.
Roles are free-form permissions (e.g. admin,
post, comment). Can be divided into three
categories:
admin,
user.post, comment.admin includes user and
manager.Roles can be "mapped" to users/groups. Otherwise a user is limited to default roles (assigned at creation) and service account roles (jobs).
Users grouped in realms can be created from the admin API or using terraform.
Common workflow includes user being redirected to keycloak for login, and client services using claims provided by keycloak for user authentication and secure communication between each other.
Otherwise keycloak can be used for granting access to jobs in some large deployment, i.e. where you can plug OpenID.