14 ms·
In Keycloak nothing made sense to me until I got myself familiar with OAuth 2.0 and OpenID Connect. Keycloaks documentation seems vast, but isn't. There is als
by schipplock 4y ago
In Keycloak nothing made sense to me until I got myself familiar with OAuth 2.0 and OpenID Connect.
Keycloaks documentation seems vast, but isn't. There is also no way to search inside their documentation. It's a pity.
A better documentation is contained in the administration web ui itself. There are so many "hints" and tooltips for almost every option there is. It really helped me a lot.
Keycloak is good software. It never failed for me. Even upgrading from 7.x.x to 16.x.x somehow just worked.
Yes, their docker image is fat, but it's also very flexible. Now that they are basing Keycloak on Quarkus instead on Wildfly, the docker image should shrink in size.
quay.io/keycloak/keycloak 18.0.0 a6bd0f949af0 15 hours ago 562MB
quay.io/keycloak/keycloak 18.0.0-legacy 421e95f49589 46 hours ago 753MB
ok, still big :).
Beware: they aren't using Docker Hub anymore. Newer versions are on Quay only (https://quay.io/repository/keycloak/keycloak https://quay.io/repository/keycloak/keycloak).
I'm happy with Keycloak. Also nice folks around Keycloak.
- imglorp 4y agoWe're still on the older one and looking forward to the Quarkus improvement specifically for boot times. Even with an empty DB, the old one takes several minutes to load and come up. It's the long pole in our install. Very happy with KC otherwise. We make heavy use of its nice API to create providers and clients at install time.
- chrisoverzero 4y ago> Beware: they aren't using Docker Hub anymore. Newer versions are on Quay only Oh, right, Quaycloak.
- zeepzeep 4y agoQuaaludes... what?
- mooreds 4y ago> Beware: they aren't using Docker Hub anymore. Do you know why? Is it because of the docker hub pricing changes? I found this discussion on the mailing list but didn't see a reason why: https://lists.jboss.org/pipermail/keycloak-user/2019-March/017476.html https://lists.jboss.org/pipermail/keycloak-user/2019-March/0...
- mkdirp 4y agoPretty sure it's because the core devs are RH employees, who owns Quay. Seems reasonable to keep things on your own infra. Having said that, I know there has been some falling out between RH and Docker some time ago, which was one of the reason RH ended up creating Podman.
- papercrane 4y agoThis is the publicly stated reasoning: https://lists.jboss.org/pipermail/keycloak-user/2019-March/017454.html https://lists.jboss.org/pipermail/keycloak-user/2019-March/0... Mostly I think the answer is just that it's a Red Hat project and Red Hat wants to use their ecosystem.
- deleted 4y ago[deleted]
- sascha_sl 4y agoYou should really be building your own multi-stage container so you can prebake KC_FEATURES and KC_DB into the image. https://www.keycloak.org/server/containers https://www.keycloak.org/server/containers
- schipplock 4y agoWe still use an old version without Quarkus :). But yes, that's the way to go.
- Perseids 4y ago> In Keycloak nothing made sense to me until I got myself familiar with OAuth 2.0 and OpenID Connect. Hot take: OAuth2 is a really shitty protocol. It is one of those technologies that get a lot of good press, because it enables you to do stuff you wouldn't be able to do in standardized manner without resorting to abysmal alternatives (SAML in this case). And because of that it shines in comparison. But looking at it from a secure protocol design perspective it is riddled with accidental complexity producing unnecessary footguns. The main culprit is the idea to transfer security critical data over URLs. IIUC this was done to reduce state on the involved servers, but that advantage has completely vanished, if you follow today's best practices to use the PKCE, state and nonce parameter (together with the authorization code flow). And more than half of the attacks you need to prevent or mitigate with the modern extensions to the original OAuth concepts are possible because grabbing data from URLs is so easy: An attacker can trick you to use a malicious redirect URL? Lock down the possible redirects with an explicitly managed URL allow-list. URLs can be cached and later accessed by malicious parties? Don't transmit the main secret (bearer token) via URL parameters, but instead transmit an authorization code which you can exchange (exactly) once for the real bearer token. A malicious app can register your URL schema in your smartphone OS? Add PKCE via server-side state to prove that the second request is really from the same party as the first request... It could have been so simple (see [1] for the OAuth2 roles): The client (third party application) opens a session at the authorization server, detailing the requested rights and scopes. The authorization server returns two random IDs – a public session identifier, and a secret session identifier for the client – and stores everything in the database. The client directs the user (resource owner) to the authorization server giving them the public session identifier (thus the user and possible attackers only ever have the possibility to see the public session identifier). The authorization server uses the public session identifier to look up all the details of the session (requested rights and scopes and who wants access) and presents that to the user (resource owner) for approval. When that is given, the user is directed back to the client carrying only the public session identifier (potentially not even that is necessary, if the user can be identified via cookies), and the client can fetch the bearer token from the authorization server using the secret session identifier. That would be so much easier... Alas, we are stuck with OAuth2 for historic reasons. [1] https://aaronparecki.com/oauth-2-simplified/#roles https://aaronparecki.com/oauth-2-simplified/#roles
- erwincoumans 4y agoThanks for the thumbs up! >> 562MB Curious, why is the Quay image/container so large? Is there a way to list the contents without downloading it?
- yrro 4y agoThe base image (registry.access.redhat.com/ubi8-minimal) is about 100 MiB. ID CREATED CREATED BY SIZE COMMENT a6bd0f949af01b5680767225c3ac2b428d9b6921a6a9a420f6189f2523931c4c 18 hours ago ENTRYPOINT ["/opt/keycloak/bin/kc.sh"] 0 B buildkit.dockerfile.v0 <missing> 18 hours ago EXPOSE map[8443/tcp:{}] 0 B buildkit.dockerfile.v0 <missing> 18 hours ago EXPOSE map[8080/tcp:{}] 0 B buildkit.dockerfile.v0 <missing> 18 hours ago USER 1000 0 B buildkit.dockerfile.v0 <missing> 18 hours ago RUN /bin/sh -c microdnf update -y && microdnf install -y java-11-openjdk-headless && microdnf clean all && rm -rf /var/cache/yum/* && echo "keycloak:x:0:root" >> /etc/group && echo "keycloak:x:1000:0:keycloak user:/opt/keycloak:/sbin/nologin" >> /etc/passwd # buildkit 272 MB buildkit.dockerfile.v0 <missing> 18 hours ago COPY /opt/keycloak /opt/keycloak # buildkit 192 MB buildkit.dockerfile.v0 1ecf95eda522cf8db84ac321e43a353deea042480ed4e97e02c5290eb53390c3 5 days ago 20.5 kB <missing> 5 days ago 107 MB Imported from -
- password4321 4y ago> Keycloaks documentation seems vast, but isn't. There is also no way to search inside their documentation. This is one area where incentives don't align correctly for open source projects that offer commercial support.
- freedomben 4y agoDisclaimer: Former Red Hatter but worked on OpenShift, not Keycloak Working as a person providing commercial support for open source projects, I promise it doesn't actually work that way. Incentives are entirely for creating good documentation. Having crappy docs only hurts project adoption for paying and non-paying customers, increases the support burden, and wastes the time of your employees (who are the primary consumers of that documentation). Usually documentation isn't great because writing (and maintaining!) good documentation is really hard. It's a continual effort and it takes engineer time away from bug fixes and feature dev, two things for which there is never ending demand for. Edit: Pro-Tip: With Red Hat projects (like Keycloak, OKD, etc) it's always worth looking at the RH product docs as well as "open source" docs. For example if you use OKD, check OpenShift docs as well as OKD docs. You do (unfortunately and I wish they'd remove this) usually have to log in to a Red Hat account but you don't have to pay. You can create a free account and use that.
- password4321 4y agoThank you for taking the time to share your first-hand perspective!
- _jal 4y agoI can tell you that at least as of late last year, the OpenShift install docs omitted key details for setting it up. We were unable to do so until contacting RH and getting additional instructions - I forget the all the details, part of it involved creating DNS records mentioned nowhere in the docs.
- pas 4y agoHow open is OpenShift? Is there a bug where this is tracked and are people contributing at least through issue comments? And response from committers?
- jonkoops 4y agoWe're actually working on a new version of the Administration UI at the moment (I'm one of the devs) so this is useful feedback. We're looking for folks to try it out, so take a look at https://github.com/keycloak/keycloak-admin-ui/ https://github.com/keycloak/keycloak-admin-ui/. You can try it out on the latest Keycloak by passing the --features=admin2 flag on startup.
- newera2016 4y agoWe have way too many issues with KeyCloak. Sometimes I wonder why did we integrate this. One of the main issue is when you authorize by Github but cancel the authentication, it redirects to KeyCloak page rather than our login page. Couldn't find any solution yet.
- mpfundstein 4y agoisnt it open source?
- tamarok 4y agoWill this have an impact on the auth screens and the related theming?
- jonkoops 4y agoTheming the Administration UI in the new version is a lot harder as it relies more on JavaScript for rendering than FreeMarker templates in the old one. We're keeping the option to use the old interface around until this has been mitigated. That said, we are now relying on PatternFly (https://www.patternfly.org https://www.patternfly.org), which allows quite some customization through CSS variables. As for the authorization screens, these are out of scope for the changes we're doing here. But they will probably get pulled into their own refactor at some point.
- unixhero 4y agoI come from cybersec and I want to give you mad props for this product and project. It fills gaps in many places!
- yrro 4y agoCan you disclose the number of users & apps you have? Are you using Keycloak or do you pay for Red Hat Single Sign-On (for context, that's the name of the downstream product that Red Hat sell subscriptions for).
- schipplock 4y agoWe are using keycloak, not SSO. There is no long-term-support keycloak version available, so we are considering buying into Redhat SSO.
- X-Istence 4y agoThe downside to using Red Hat Single Sign-On is that it is a vastly inferior product to using Keycloak upstream as it is so many versions behind. This means that bug fixes and features haven't trickled down yet. Although RH SSO 7.5 jumped from Keycloak version 9.0.17 (in RH SSO 7.4) to 15.0.2 so there's some improvement there... but Keycloak just released 18.0.0...
- 0xbadcafebee 4y ago> Newer versions are on Quay only Thanks for mentioning this, I didn't realize Keycloak is a RedHat product. I'll plan to move to something else. Anything RedHat makes turns into a catastrophe.
- paulmd 4y ago> Keycloaks documentation seems vast, but isn't. There is also no way to search inside their documentation. It's a pity. > A better documentation is contained in the administration web ui itself. There are so many "hints" and tooltips for almost every option there is. It really helped me a lot. To echo everyone else: the Keycloak documentation does not do a good job of hand-holding you at all, and the number of possible ways you can configure and use the system and the amount of jargon and terminology used is massively overwhelming to someone trying to get started. It would be very helpful to have some "white paper"-esque summaries that walk you through some simple, typical use-cases. I looked through the docs quickly before making this post and as an example here's a basic task for initial setup ("hook up an IDP", basically giving keycloak its database of users), and it's utterly incomprehensible to any human being who doesn't already know how to work the system and really essentially worthless even then. It's just... reading me the command line options and a couple config files? What do any of those values even mean? This is core functionality for Keycloak, and the documentation consists of "yeah, here's a command line with placeholders and a text file syntax, good luck bitches!". https://www.keycloak.org/server/configuration-provider https://www.keycloak.org/server/configuration-provider Honestly I feel like you could do better simply by jumping into the UI and playing with options, it's not entirely unintuitive what's going on in the UI, but the docs are basically incomprehensible. I actually know of several projects that have pretty much bogged down because of Keycloak configuration or role/privilege mis-configuration issues and it's not hard to see why. It's the turing tar-pit of IDP, everything is possible and nothing is easy (or documented). Which is a shame because it seems like an awesome piece of software, just inscrutible to the un-initiated. As others are noting, I'm sure some of this is due to OAuth2 being an inscrutable piece of shit in general, same thing, it tries to do everything and it's so un-opinionated that you end up with a bunch of basically incompatible implementations that are each effectively their own "standard" anyway. (posted this on the wrong child, moving it to the parent)
- tamarok 4y agoFor the most part I am also happy with Keycloak, but they could do a far better job documenting things, especially their language adapters. For example the "Readme" for the `keycloak-connect` Node.js package has a link to documentation, but that documentation fails to document anything around the package. Likewise I had better luck once I understood OpenID and then treating Keycloak as an extension of that. I even ended up writing my own code to deal with the bearer token passed to our API, because I couldn't find anything. If anyone is interested I can share it, but it isn't anything amazing. Most of my best help came from outside of the Keycloak support groups and instead reaching out to other people who use Keycloak.
- johnmarcus 4y agoI'm litterally about to jump from 8 to 17 this week, so that's good to hear. It seemed seamless on my local setup and was wondering if it was just too good to be true. It's a great piece of software. You are correct about the documentation. I find the tragedy of open source documentation is that the people who need it most - the novices - are the ones whom could write it best - if they only knew if what they were saying was accurate. And then by the time you become an old-timer, and know thy ways, you just want to wipe your hands and walk away, because your tired....and still not sure if all your knowledge is accurate. But anyway, once it's all figured out, it runs very reliably.