Keycloak
Keycloak is set up as a stand-alone server. Be aware of the limitations!
Data is stored in a PostgreSQL database. The database name and credentials are part of the docker-compose file.
This setup for the CICD-toolbox is intended to be run locally on a laptop in order to develop and test the toolkit's operation. As such all systems in the CICD-toolbox are configured in a minimal configuration, i.e. no clustering, no K8s, etc. as this minimizes the resources needed. This is also the case for Keycloak: it is configured in stand-alone mode. The Keycloak database is separate and implemented on s shared PostgreSQL container. Keycloak used the stand-alone ha.xml for configuration as per the docker setup.
Keycloak uses certificates to safeguard data exchanged between Keycloak and a client. In order for this to work, keycloak needs a certificate that contains the system name in the subject. In the initial setup of the keycloak container, this system name is called localhost in a self-signed certificate. This is not accepted on java based systems such as Jenkins and Nexus.
In order to change this, either a commercial certificate must be purchased, or a new local certificate must be created locally and imported into the systems validating the certificate, such as the Jenkins keystore.
As Docker networking includes dns functionality, systems can reach each other on the docker network using the container name. As such, Keycloak is reachable on the "tooling" network in docker as "keycloak". Using just "keycloak" on your local machine will only work if "172.16.11.11 keycloak" is added to the hosts file on your local system. Now the name keycloak can also be used inside the certificate.
Keycloak supports OpenID and SAML. As OpenID is newer, this pipeline intends to use OpenID where possible. For Java based clients:
Keycloak uses a hierarchical model. The Highest level is the Realm. The CICD-toolbox realm is called "NetCICD" (what else). Properties of the realm can be modified in the create-realm.sh shell script.
Java adapter JSON:
Resource: clientID, so Jenkins, Nexus, etc
Realm Public key: not used
Auth-server-url" : "https://keycloak:8443/auth" Be aware: Keycloak somehow adds a / on the end :( which breaks the Jenkins plugin
SSL-required: external, so we can still sniff the traffic for troubleshooting
Confidential-port: default
use-resource-role-mappings: If set to true, the adapter will look inside the token for application level role mappings for the user. If false, it will look at the realm level for user role mappings. As we use client roles, we should say true here.
public-client: false, we need a confidential client in order to permit service accounts
cors*: default
bearer-only: This should be set to true for services. If enabled the adapter will not attempt to authenticate users, but only verify bearer tokens. As all systems have some sort of user interaction, leave this default (false)
autodetect-bearer-only: This should be set to true if your application serves both a web application and web services (e.g. SOAP or REST). It allows you to redirect unauthenticated users of the web application to the Keycloak login page, but send an HTTP 401 status code to unauthenticated SOAP or REST clients instead as they would not understand a redirect to the login page. Keycloak auto-detects SOAP or REST clients based on typical headers like X-Requested-With, SOAPAction or Accept. The default value is false. I guess this needs to be true...
The next level are the clients: the servers using Keycloak for AAA. A client is created for each of the containers in the docker-compose file that is intended to be accessed by users on a regular basis. Clients and properties of clients can be modified in the create-realm.sh shell script.
Each clients has a service account that can be used to execute things on the client. The amount of access can be managed through roles.
For each client, so-called client roles are created. Keycloak also offers the possibility for generic roles, but creating client specific roles provides more insight in which capabilities a user actually has and on which system.
In addition, the client scope is limited: only the roles defined for that client are exposed in the access token. By default, all roles assigned to the user on all clients are in the access token.
Roles and properties of roles can be modified in the create-realm.sh shell script.