Rootmanual:Keycloak: Skillnad mellan sidversioner
Busk (diskussion | bidrag) (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...') |
Busk (diskussion | bidrag) |
||
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. |
Versionen från 28 september 2022 kl. 21.20
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
keytool -genkey -alias localhost -keyalg RSA -keystore keycloak.jks -validity 10950
lägg filen i /opt/keycloak/standalone/configuration/
Se till att standalone-servern är igång, starta sedan jboss-cli (bin/jboss-cli)
$ 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¤)
Kolla att standalone/configuration/standalone.xml innehåller typ
<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>
Se till att https-listenern har undertowrealmen, typ
<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>
För utgående anslutningar kan man vilja lägga till följande spi bland de andra
<spi name="connectionsHttpClient"> <provider name="default" enabled="true"> <properties> <property name="connection-pool-size" value="256"/> </properties> </provider> </spi>
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
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 / > ProxyPass https://localhost:8443/ ProxyPassReverse http://localhost:8443/ </Location>
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 [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
Kör man SELinux och vill att startupskriptet ska kunna köras av systemd behöver det ha bin_t-flagga
chcon -t bin_t /opt/keycloak/bin/standalone.sh
Därefter bör det gå att köra efter
systemctl daemon-reload systemctl enable keycloak systemctl start keycloak
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:
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
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.
TODO
Beskriva:
- Uppsättning av realm med federering mot ldap
- Roles claim