Rootmanual:Keycloak: Skillnad mellan sidversioner
Busk (diskussion | bidrag) |
Busk (diskussion | bidrag) Ingen redigeringssammanfattning |
||
(2 mellanliggande sidversioner av samma användare visas inte) | |||
Rad 1: | Rad 1: | ||
Keycloak är en identity manager skriven i Java och som utvecklas av Redhat. Den är byggd ovanpå applikationsservern WildFly (tidigare JBoss), och en relevant feature för Lysator är att den kan tillhandahålla SSO via t.ex. openid connect och kan federera med ldap. Detta innebär att när du loggar in på t.ex. datorhandboken så gör du det via keycloak, som autentiserar dig mot ldap och eventuellt också tilldelar dig roller utifrån de grupptillhörigheter som du har i ldap (t.ex. så kan man sätta upp att medlemmar i gruppen lysroot får en roll "root" i sin claim, vilket i sin tur kan användas för auktorisering i den webapp du loggar in på). |
Keycloak är en identity manager skriven i Java och som utvecklas av Redhat. Den är byggd ovanpå applikationsservern WildFly (tidigare JBoss), och en relevant feature för Lysator är att den kan tillhandahålla SSO (single sign on) via t.ex. openid connect och kan federera med ldap. Detta innebär att när du loggar in på t.ex. datorhandboken så gör du det via keycloak, som autentiserar dig mot ldap och eventuellt också tilldelar dig roller utifrån de grupptillhörigheter som du har i ldap (t.ex. så kan man sätta upp att medlemmar i gruppen lysroot får en roll "root" i sin claim, vilket i sin tur kan användas för auktorisering i den webapp du loggar in på). |
||
Installationen har i princip följt den dokumentation som finns tillgänglig (ex. https://www.keycloak.org/ |
Installationen har i princip följt den dokumentation som finns tillgänglig (ex. https://www.keycloak.org/guides ) |
||
== Installation == |
|||
# Sätt upp en postgresserver och skapa en databas som heter keycloak, samt en användare till denna databas |
|||
Lite blandade anteckningar från uppsättningen av keycloak |
|||
# Packa upp zipfil du laddar ner |
|||
# Du kommer först köra keycloak i dev-läge, och då vill den bara kommas åt lokalt, så sätt t.ex. upp nginx som en reverse proxy (enligt nedan), fast med proxy_bind konfigurerat serverns ipv4 så att webbanrop ser ut att komma från localhost. |
|||
# Konfigurera inloggningsuppgifter för postgres samt tls i conf/keycloak.conf. Du behöver ett cert och en nyckel för fqdn. |
|||
# Kör <tt>KEYCLOAK_ADMIN=anvnamn KEYCLOAK_PASSWORD=lösenord ./bin/kc start-dev</tt> |
|||
# Konfa mailserver i webbgucket |
|||
# Skapa en ny realm (om du har en exporterad realm från tidigare har du möjlighet att ladda upp denna json-fil - förslagsvis kan du prepopulera denna med secrets och så vidare så att man slipper en massa jobb med att regenerera dessa och sedan byta på klienterna, exportfunktionen exporterar nämligen inte dessa) |
|||
# Stäng ner servern igen, kör <tt>./bin/kc build</tt> för att bygga om applikationen |
|||
# Lägg till ldapserverns certifikat i truststoren enligt nedan |
|||
# Skapa en användare på servern, typ svc-keycloak, lägg applikationen under /opt, skapa en systemd-service |
|||
# När du enable:at och startat den så ska det hela förhoppningsvis funka. |
|||
== |
== Reverse proxy == |
||
Framför java-applikationsservern sitter en reverse proxy (nginx). Kör man SELinux och vill att apache ska kunna ansluta via nätverk kan man behöva tillåta det genom |
|||
Taget från https://www.keycloak.org/docs/latest/server_installation/#_network |
|||
<pre>setsebool -P httpd_can_network_connect on </pre> |
|||
<pre>keytool -genkey -alias localhost -keyalg RSA -keystore keycloak.jks -validity 10950</pre> |
|||
lägg filen i /opt/keycloak/standalone/configuration/ |
|||
Se till att standalone-servern är igång, starta sedan jboss-cli (bin/jboss-cli) |
|||
I övrigt bör det gå bra att låta letsencrypts certbot sätta upp cert och så vidare och att man konfar en location i stil med |
|||
<pre> |
<pre> |
||
location { |
|||
$ connect |
|||
proxy_set_header Forwarded $proxy_add_forwarded; |
|||
$ /core-service=management/security-realm=UndertowRealm:add() |
|||
proxy_set_header X-Forwarded-Host $host:443; |
|||
$ /core-service=management/security-realm=UndertowRealm/server-identity=ssl:add(keystore-path=keycloak.jks, keystore-relative-to=jboss.server.config.dir, keystore-password=¤NÅGOTLÄMPLIGT¤) |
|||
proxy_set_header X-Forwarded-Server $host; |
|||
proxy_set_header X-Forwarded-Port 443; |
|||
proxy_set_header X-Forwarded-Proto https; |
|||
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; |
|||
proxy_pass https://130.236.254.116:8443; |
|||
} |
|||
</pre> |
</pre> |
||
För forwarded-headern behöver du även lägga till nedanstående, t.ex. ovanför serverblocket: |
|||
Kolla att standalone/configuration/standalone.xml innehåller typ |
|||
<pre> |
<pre> |
||
map $remote_addr $proxy_forwarded_elem { |
|||
<security-realm name="UndertowRealm"> |
|||
# IPv4 addresses can be sent as-is |
|||
<server-identities> |
|||
~^[0-9.]+$ "for=$remote_addr"; |
|||
<ssl> |
|||
<keystore path="keycloak.jks" relative-to="jboss.server.config.dir" keystore-password="¤NÅGOTLÄMPLIGT¤" /> |
|||
</ssl> |
|||
</server-identities> |
|||
</security-realm> |
|||
</pre> |
|||
# IPv6 addresses need to be bracketed and quoted |
|||
Se till att https-listenern har undertowrealmen, typ |
|||
~^[0-9A-Fa-f:.]+$ "for=\"[$remote_addr]\""; |
|||
<pre> |
|||
<subsystem xmlns="urn:jboss:domain:undertow:12.0"> |
|||
<buffer-cache name="default"/> |
|||
<server name="default-server"> |
|||
<https-listener name="https" socket-binding="https" security-realm="UndertowRealm"/> |
|||
... |
|||
</subsystem> |
|||
</pre> |
|||
# Unix domain socket names cannot be represented in RFC 7239 syntax |
|||
För utgående anslutningar kan man vilja lägga till följande spi bland de andra |
|||
default "for=unknown"; |
|||
} |
|||
map $http_forwarded $proxy_add_forwarded { |
|||
<pre> |
|||
# If the incoming Forwarded header is syntactically valid, append to it |
|||
<spi name="connectionsHttpClient"> |
|||
"~^(,[ \\t]*)*([!#$%&'*+.^_`|~0-9A-Za-z-]+=([!#$%&'*+.^_`|~0-9A-Za-z-]+|\"([\\t \\x21\\x23-\\x5B\\x5D-\\x7E\\x80-\\xFF]|\\\\[\\t \\x21-\\x7E\\x80-\\xFF])*\"))?(;([!#$%&'*+.^_`|~0-9A-Za-z-]+=([!#$%&'*+.^_`|~0-9A-Za-z-]+|\"([\\t \\x21\\x23-\\x5B\\x5D-\\x7E\\x80-\\xFF]|\\\\[\\t \\x21-\\x7E\\x80-\\xFF])*\"))?)*([ \\t]*,([ \\t]*([!#$%&'*+.^_`|~0-9A-Za-z-]+=([!#$%&'*+.^_`|~0-9A-Za-z-]+|\"([\\t \\x21\\x23-\\x5B\\x5D-\\x7E\\x80-\\xFF]|\\\\[\\t \\x21-\\x7E\\x80-\\xFF])*\"))?(;([!#$%&'*+.^_`|~0-9A-Za-z-]+=([!#$%&'*+.^_`|~0-9A-Za-z-]+|\"([\\t \\x21\\x23-\\x5B\\x5D-\\x7E\\x80-\\xFF]|\\\\[\\t \\x21-\\x7E\\x80-\\xFF])*\"))?)*)?)*$" "$http_forwarded, $proxy_forwarded_elem"; |
|||
<provider name="default" enabled="true"> |
|||
<properties> |
|||
<property name="connection-pool-size" value="256"/> |
|||
</properties> |
|||
</provider> |
|||
</spi> |
|||
</pre> |
|||
# Otherwise, replace it |
|||
default "$proxy_forwarded_elem"; |
|||
} |
|||
== Reverse proxy == |
|||
Framför java-applikationsservern sitter en reverse proxy (Apache httpd). Kör man SELinux och vill att apache ska kunna ansluta via nätverk kan man behöva tillåta det genom |
|||
<pre>setsebool -P httpd_can_network_connect on </pre> |
|||
I övrigt bör det gå bra att låta letsencrypts certbot sätta upp cert och så vidare och att man konfar en location i stil med |
|||
<pre> |
|||
<Location / > |
|||
ProxyPass https://localhost:8443/ |
|||
ProxyPassReverse http://localhost:8443/ |
|||
</Location> |
|||
</pre> |
</pre> |
||
Rad 84: | Rad 73: | ||
[Unit] |
[Unit] |
||
Description=Keycloak |
Description=Keycloak |
||
After=network.target |
#After=network.target |
||
After=postgresql.service |
|||
[Service] |
[Service] |
||
Type=idle |
Type=idle |
||
ExecStart=/opt/keycloak/bin/ |
ExecStart=/opt/keycloak/bin/kc.sh start |
||
TimeoutStartSec=600 |
TimeoutStartSec=600 |
||
TimeoutStopSec=600 |
TimeoutStopSec=600 |
||
Rad 98: | Rad 88: | ||
</pre> |
</pre> |
||
Kör man SELinux och vill att startupskriptet ska kunna köras av systemd behöver det ha bin_t-flagga |
Kör man SELinux och vill att startupskriptet ska kunna köras av systemd behöver det ev ha bin_t-flagga |
||
<pre> |
<pre> |
||
chcon -t bin_t /opt/keycloak/bin/ |
chcon -t bin_t /opt/keycloak/bin/kc.sh |
||
</pre> |
</pre> |
||
Rad 110: | Rad 100: | ||
</pre> |
</pre> |
||
== LDAP-serverns certifikat i keycloaks truststore == |
|||
== Inloggning mot ldap slutar fungera == |
|||
Du använder kanske lämpligast openssl:s cli-verktyg för att hämta certifikatet och lägger det i /opt/keycloak/conf/truststores/, t.ex. med följande kommando: |
|||
Loggar för applikationsservern bör finnas under data/log i installationskatalogen (/opt/keycloak/[standalone]). Mer info om loggning finns på https://www.keycloak.org/server/logging (man kan t.ex. få mer pratiga loggningar till konsollen för felsökning) |
|||
Detta har tidigare berott på att ingen separat keystore för keycloak var uppsatt, så den använde den som JDK:n tillhandahåller. Vid en uppdatering av JDK-version följer givetvis inte den manuellt inlagda cert med, och man behövde lägga till dem igen enligt nedan: |
|||
<pre> |
<pre> |
||
openssl x509 -in <(openssl s_client -connect trocca.ad.lysator.liu.se:636 -prexit 2>/dev/null) -out |
openssl x509 -in <(openssl s_client -connect trocca.ad.lysator.liu.se:636 -prexit 2>/dev/null) -out /opt/keycloak/conf/truststores/trocca.pem |
||
keytool -importcert -file ~/example.crt -alias example -keystore /etc/java/java-11-openjdk/java-11-openjdk-11.0.14.0.9-2.el8_5.x86_64/lib/security/cacerts -storepass changeit |
|||
</pre> |
</pre> |
||
== Uppgradering == |
|||
Sista raden behöver uppdateras till senaste version där "cacerts" ligger. Därefter omstart av keycloak-tjänsten. |
|||
I princip följer man instruktioner på https://www.keycloak.org/docs/latest/upgrading/index.html#_upgrading dvs: |
|||
Nu har det istället lösts genom att konfigurera en truststore åt keycloak där man kan lägga till ldap-serverns certifikat, enligt nedan: |
|||
# Stäng ner keycloak (systemctl stop keycloak) |
|||
Lägg till i standalone.xml |
|||
# Flytta undan /opt/keycloak någon annanstans (mv /opt/keycloak /opt/keycloak-old) |
|||
<pre> |
|||
# Ev. radera data/tx-object-store |
|||
<spi name="truststore"> |
|||
# Backa upp databasen (pg_dump keycloak > keycloakdb-old.sql) |
|||
<provider name="file" enabled="true"> |
|||
# Ladda ner och extrahera den nya versionen, lägg katalogen som den nya /opt/keycloak |
|||
<properties> |
|||
# Kopiera conf/ från den gamla installationen till den nya (providers/ och themes/ är i dagsläget tomma eftersom vi inte har några ytterligare providers eller teman än de inbyggda, men det skadar ju inte att kopiera över dessa med) |
|||
<property name="file" value="/opt/keycloak/truststore.jks" /> |
|||
# kör bin/kc.sh build för att bygga installationen |
|||
<property name="password" value="¤NÅGOTLÄMPLIGT¤" /> |
|||
# chown svc-keycloak:svc-keycloak -R /opt/keycloak |
|||
<property name="hostname-verification-policy" value="WILDCARD"/> |
|||
# starta keycloak-servicen (systemctl start keycloak) |
|||
<property name="disabled" value="false"/> |
|||
# kolla loggarna att det ser ut att ha gått bra, om inte, börja felsöka (journalctl -f -u keycloak) |
|||
</properties> |
|||
# Prova att logga in i admingränssnittet och se om versionsnumret verkar stämma |
|||
</provider> |
|||
</pre> |
|||
<pre> |
|||
keytool -genkey -alias localhost -keyalg RSA -keystore /opt/keycloak/truststore.jks -validity 3650 # Skapar keystoren. Sätt lösenord till ¤NÅGOTLÄMPLIGT¤ |
|||
openssl x509 -in <(openssl s_client -connect trocca.ad.lysator.liu.se:636 -prexit 2>/dev/null) -out ~/example.crt |
|||
keytool -importcert -file ~/example.crt -alias trocca -keystore /opt/keycloak/truststore.jks -storepass ¤NÅGOTLÄMPLIGT¤ |
|||
</pre> |
|||
== TODO == |
== TODO == |
Nuvarande version från 27 september 2024 kl. 14.30
Keycloak är en identity manager skriven i Java och som utvecklas av Redhat. Den är byggd ovanpå applikationsservern WildFly (tidigare JBoss), och en relevant feature för Lysator är att den kan tillhandahålla SSO (single sign on) via t.ex. openid connect och kan federera med ldap. Detta innebär att när du loggar in på t.ex. datorhandboken så gör du det via keycloak, som autentiserar dig mot ldap och eventuellt också tilldelar dig roller utifrån de grupptillhörigheter som du har i ldap (t.ex. så kan man sätta upp att medlemmar i gruppen lysroot får en roll "root" i sin claim, vilket i sin tur kan användas för auktorisering i den webapp du loggar in på).
Installationen har i princip följt den dokumentation som finns tillgänglig (ex. https://www.keycloak.org/guides )
Installation
- Sätt upp en postgresserver och skapa en databas som heter keycloak, samt en användare till denna databas
- Packa upp zipfil du laddar ner
- Du kommer först köra keycloak i dev-läge, och då vill den bara kommas åt lokalt, så sätt t.ex. upp nginx som en reverse proxy (enligt nedan), fast med proxy_bind konfigurerat serverns ipv4 så att webbanrop ser ut att komma från localhost.
- Konfigurera inloggningsuppgifter för postgres samt tls i conf/keycloak.conf. Du behöver ett cert och en nyckel för fqdn.
- Kör KEYCLOAK_ADMIN=anvnamn KEYCLOAK_PASSWORD=lösenord ./bin/kc start-dev
- Konfa mailserver i webbgucket
- Skapa en ny realm (om du har en exporterad realm från tidigare har du möjlighet att ladda upp denna json-fil - förslagsvis kan du prepopulera denna med secrets och så vidare så att man slipper en massa jobb med att regenerera dessa och sedan byta på klienterna, exportfunktionen exporterar nämligen inte dessa)
- Stäng ner servern igen, kör ./bin/kc build för att bygga om applikationen
- Lägg till ldapserverns certifikat i truststoren enligt nedan
- Skapa en användare på servern, typ svc-keycloak, lägg applikationen under /opt, skapa en systemd-service
- När du enable:at och startat den så ska det hela förhoppningsvis funka.
Reverse proxy
Framför java-applikationsservern sitter en reverse proxy (nginx). Kör man SELinux och vill att apache ska kunna ansluta via nätverk kan man behöva tillåta det genom
setsebool -P httpd_can_network_connect on
I övrigt bör det gå bra att låta letsencrypts certbot sätta upp cert och så vidare och att man konfar en location i stil med
location { proxy_set_header Forwarded $proxy_add_forwarded; proxy_set_header X-Forwarded-Host $host:443; proxy_set_header X-Forwarded-Server $host; proxy_set_header X-Forwarded-Port 443; proxy_set_header X-Forwarded-Proto https; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_pass https://130.236.254.116:8443; }
För forwarded-headern behöver du även lägga till nedanstående, t.ex. ovanför serverblocket:
map $remote_addr $proxy_forwarded_elem { # IPv4 addresses can be sent as-is ~^[0-9.]+$ "for=$remote_addr"; # IPv6 addresses need to be bracketed and quoted ~^[0-9A-Fa-f:.]+$ "for=\"[$remote_addr]\""; # Unix domain socket names cannot be represented in RFC 7239 syntax default "for=unknown"; } map $http_forwarded $proxy_add_forwarded { # If the incoming Forwarded header is syntactically valid, append to it "~^(,[ \\t]*)*([!#$%&'*+.^_`|~0-9A-Za-z-]+=([!#$%&'*+.^_`|~0-9A-Za-z-]+|\"([\\t \\x21\\x23-\\x5B\\x5D-\\x7E\\x80-\\xFF]|\\\\[\\t \\x21-\\x7E\\x80-\\xFF])*\"))?(;([!#$%&'*+.^_`|~0-9A-Za-z-]+=([!#$%&'*+.^_`|~0-9A-Za-z-]+|\"([\\t \\x21\\x23-\\x5B\\x5D-\\x7E\\x80-\\xFF]|\\\\[\\t \\x21-\\x7E\\x80-\\xFF])*\"))?)*([ \\t]*,([ \\t]*([!#$%&'*+.^_`|~0-9A-Za-z-]+=([!#$%&'*+.^_`|~0-9A-Za-z-]+|\"([\\t \\x21\\x23-\\x5B\\x5D-\\x7E\\x80-\\xFF]|\\\\[\\t \\x21-\\x7E\\x80-\\xFF])*\"))?(;([!#$%&'*+.^_`|~0-9A-Za-z-]+=([!#$%&'*+.^_`|~0-9A-Za-z-]+|\"([\\t \\x21\\x23-\\x5B\\x5D-\\x7E\\x80-\\xFF]|\\\\[\\t \\x21-\\x7E\\x80-\\xFF])*\"))?)*)?)*$" "$http_forwarded, $proxy_forwarded_elem"; # Otherwise, replace it default "$proxy_forwarded_elem"; }
Se till att brandväggen är öppen (men öppna inte 8443)
firewall-cmd --permanent --add-port=443/tcp firewall-cmd --permanent --add-port=80/tcp firewall-cmd --reload
Systemd
Fil /etc/systemd/system/keycloak.service med innehåll typ:
[Unit] Description=Keycloak #After=network.target After=postgresql.service [Service] Type=idle ExecStart=/opt/keycloak/bin/kc.sh start TimeoutStartSec=600 TimeoutStopSec=600 User=svc-keycloak Group=svc-keycloak [Install] WantedBy=multi-user.target
Kör man SELinux och vill att startupskriptet ska kunna köras av systemd behöver det ev ha bin_t-flagga
chcon -t bin_t /opt/keycloak/bin/kc.sh
Därefter bör det gå att köra efter
systemctl daemon-reload systemctl enable keycloak systemctl start keycloak
LDAP-serverns certifikat i keycloaks truststore
Du använder kanske lämpligast openssl:s cli-verktyg för att hämta certifikatet och lägger det i /opt/keycloak/conf/truststores/, t.ex. med följande kommando:
openssl x509 -in <(openssl s_client -connect trocca.ad.lysator.liu.se:636 -prexit 2>/dev/null) -out /opt/keycloak/conf/truststores/trocca.pem
Uppgradering
I princip följer man instruktioner på https://www.keycloak.org/docs/latest/upgrading/index.html#_upgrading dvs:
- Stäng ner keycloak (systemctl stop keycloak)
- Flytta undan /opt/keycloak någon annanstans (mv /opt/keycloak /opt/keycloak-old)
- Ev. radera data/tx-object-store
- Backa upp databasen (pg_dump keycloak > keycloakdb-old.sql)
- Ladda ner och extrahera den nya versionen, lägg katalogen som den nya /opt/keycloak
- Kopiera conf/ från den gamla installationen till den nya (providers/ och themes/ är i dagsläget tomma eftersom vi inte har några ytterligare providers eller teman än de inbyggda, men det skadar ju inte att kopiera över dessa med)
- kör bin/kc.sh build för att bygga installationen
- chown svc-keycloak:svc-keycloak -R /opt/keycloak
- starta keycloak-servicen (systemctl start keycloak)
- kolla loggarna att det ser ut att ha gått bra, om inte, börja felsöka (journalctl -f -u keycloak)
- Prova att logga in i admingränssnittet och se om versionsnumret verkar stämma
TODO
Beskriva:
- Uppsättning av realm med federering mot ldap
- Roles claim