Rootmanual:Keycloak - Versionshistorik

Busk: /* Uppgradering */

2025-03-18T09:49:31Z

Uppgradering

← Äldre version		Versionen från 18 mars 2025 kl. 11.49
Rad 115:		Rad 115:
	# Flytta undan /opt/keycloak någon annanstans (mv /opt/keycloak /opt/keycloak-old)		# Flytta undan /opt/keycloak någon annanstans (mv /opt/keycloak /opt/keycloak-old)
	# Ev. radera data/tx-object-store		# Ev. radera data/tx-object-store
	# Backa upp databasen (pg_dump keycloak > keycloakdb-old.sql)		# Backa upp databasen ( pg_dump -U keycloak -W -p 5432 -h localhost -d keycloak > keycloakdb-old.sql)
	# Ladda ner och extrahera den nya versionen, lägg katalogen som den nya /opt/keycloak		# 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)		# 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)

Busk den 27 september 2024 kl. 13.30

2024-09-27T13:30:48Z

@@ Rad 107: / Rad 107: @@
 openssl x509 -in <(openssl s_client -connect trocca.ad.lysator.liu.se:636 -prexit 2>/dev/null) -out /opt/keycloak/conf/truststores/trocca.pem
 </pre>
 == TODO ==

Busk: /* Reverse proxy */

2024-08-22T08:03:39Z

Reverse proxy

← Äldre version		Versionen från 22 augusti 2024 kl. 10.03
Rad 19:		Rad 19:
	== Reverse proxy ==		== 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		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

	<pre>setsebool -P httpd_can_network_connect on </pre>		<pre>setsebool -P httpd_can_network_connect on </pre>
Rad 25:		Rad 25:
	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		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~~ ~~/ >~~		location {
	proxy_set_header Forwarded $proxy_add_forwarded;		proxy_set_header Forwarded $proxy_add_forwarded;
	proxy_set_header X-Forwarded-Host $host:443;		proxy_set_header X-Forwarded-Host $host:443;
Rad 33:		Rad 33:
	proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;		proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
	proxy_pass https://130.236.254.116:8443;		proxy_pass https://130.236.254.116:8443;
		⚫	}

⚫	~~</Location>~~
	</pre>		</pre>

Busk den 22 augusti 2024 kl. 08.01

2024-08-22T08:01:48Z

Visa ändringar

Busk: /* Inloggning mot ldap slutar fungera */

2022-09-29T11:06:47Z

Inloggning mot ldap slutar fungera

← Äldre version		Versionen från 29 september 2022 kl. 13.06
Rad 114:		Rad 114:
	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)		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:
	Detta har hänt en gång sedan uppsättning, då verkade det som att troccas ldaps bytt certifikat, vilket löstes genom att importera det till keystores, ex:

	<pre>		<pre>
	openssl x509 -in <(openssl s_client -connect trocca.ad.lysator.liu.se:636 -prexit 2>/dev/null) -out ~/example.crt		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 ~~example~~ -keystore /opt/keycloak/~~standalone/configuration/keycloak~~.jks -storepass ¤NÅGOTLÄMPLIGT¤
	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		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>

	Sista raden behöver uppdateras till senaste version där "cacerts" ligger. ~~Egentligen~~ så ~~behöver man se till att~~ keycloak ~~konfigureras korrekt så att den använder egen truststore istället, eftersom det då inte blir en ny vid varje ny release av jdk, men det är just nu en TODO~~.		Sista raden behöver uppdateras till senaste version där "cacerts" ligger. Därefter omstart av keycloak-tjänsten.

			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:
	Efter omstart av applikationsservern fungerade det igen.

			Lägg till i standalone.xml
			<pre>
			<spi name="truststore">
			<provider name="file" enabled="true">
			<properties>
			<property name="file" value="/opt/keycloak/truststore.jks" />
			<property name="password" value="¤NÅGOTLÄMPLIGT¤" />
			<property name="hostname-verification-policy" value="WILDCARD"/>
			<property name="disabled" value="false"/>
			</properties>
			</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 ==

Busk: /* Inloggning mot ldap slutar fungera */

2022-09-28T20:20:14Z

Inloggning mot ldap slutar fungera

← Äldre version		Versionen från 28 september 2022 kl. 22.20
Rad 121:		Rad 121:
	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		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>

			Sista raden behöver uppdateras till senaste version där "cacerts" ligger. Egentligen så behöver man se till att keycloak konfigureras korrekt så att den använder egen truststore istället, eftersom det då inte blir en ny vid varje ny release av jdk, men det är just nu en TODO.

	Efter omstart av applikationsservern fungerade det igen.		Efter omstart av applikationsservern fungerade det igen.

Busk: Skapade sidan med '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 L...'

2022-06-08T09:11:23Z

Skapade sidan med '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 L...'

Ny sida

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å).

Installationen har i princip följt den dokumentation som finns tillgänglig (ex. https://www.keycloak.org/docs/latest/server_installation )

Lite blandade anteckningar från uppsättningen av keycloak

== TLS-konf keycloak ==

Taget från https://www.keycloak.org/docs/latest/server_installation/#_network

<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)

<pre>
$ connect
$ /core-service=management/security-realm=UndertowRealm:add()
$ /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¤)
</pre>

Kolla att standalone/configuration/standalone.xml innehåller typ
<pre>
<security-realm name="UndertowRealm">
<server-identities>
<ssl>
<keystore path="keycloak.jks" relative-to="jboss.server.config.dir" keystore-password="¤NÅGOTLÄMPLIGT¤" />
</ssl>
</server-identities>
</security-realm>
</pre>

Se till att https-listenern har undertowrealmen, typ
<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>

För utgående anslutningar kan man vilja lägga till följande spi bland de andra

<pre>
<spi name="connectionsHttpClient">
<provider name="default" enabled="true">
<properties>
<property name="connection-pool-size" value="256"/>
</properties>
</provider>
</spi>
</pre>

== 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>

Se till att brandväggen är öppen (men öppna inte 8443)

<pre>
firewall-cmd --permanent --add-port=443/tcp
firewall-cmd --permanent --add-port=80/tcp
firewall-cmd --reload
</pre>

== Systemd ==

Fil /etc/systemd/system/keycloak.service med innehåll typ:
<pre>
[Unit]
Description=Keycloak
After=network.target

[Service]
Type=idle
ExecStart=/opt/keycloak/bin/standalone.sh -b=0.0.0.0 -c standalone.xml
TimeoutStartSec=600
TimeoutStopSec=600
User=svc-keycloak
Group=svc-keycloak

[Install]
WantedBy=multi-user.target
</pre>

Kör man SELinux och vill att startupskriptet ska kunna köras av systemd behöver det ha bin_t-flagga
<pre>
chcon -t bin_t /opt/keycloak/bin/standalone.sh
</pre>

Därefter bör det gå att köra efter
<pre>
systemctl daemon-reload
systemctl enable keycloak
systemctl start keycloak
</pre>

== Inloggning mot ldap slutar fungera ==

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 hänt en gång sedan uppsättning, då verkade det som att troccas ldaps bytt certifikat, vilket löstes genom att importera det till keystores, ex:

<pre>
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 example -keystore /opt/keycloak/standalone/configuration/keycloak.jks -storepass ¤NÅGOTLÄMPLIGT¤
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>

Efter omstart av applikationsservern fungerade det igen.

== TODO ==

Beskriva:

* Uppsättning av realm med federering mot ldap

* Roles claim