Keycloak: Open-source identity and access management
keycloak.org
keycloak.org
We run it in production on GCP and it integrates nicely with the Clojure ecosystem (both on the frontend with a SPA and on the backend dealing with REST API security).
Shameless plug: I maintain the keycloak-clojure wrapper: https://github.com/jgrodziski/keycloak-clojure (You'll find some explanations of the Keycloak concepts in the README).
I will definitely take a look, then.
Well, since we are talking SAML or OIDC here - you don't really have a choice for the login/registration. The IdP provides the login and registration pages, not your application. You are free to build your own account management page, but you still have to ask Keycloak for a token.
I prefer to deal with account data and logic in a dedicated component that map with users stored in Keycloak. Even if you can associate custom attributes with user and groups, I don't think it's a good idea to do so (performance, separation of concerns, etc.).
For me Keycloak jobs is to handle authentication and authorization data and/or logic (authorization service is very well designed but a little bit complex), for simple use-case a role check in the application is enough.
This means that I can swap Google access tokens for other access tokens and vice versa.
I'm also a contributor to the "frontend" piece of keycloak that's a JavaScript library called keycloak-connect (these are known as adapters).
Also also, I'm a maintainer of https://github.com/cdbattags/lua-resty-jwt that I'm using in tandem with the Keycloak RSA public keys for auth at API gateway/network level.
Ask me anything!
it doesnt need much maintenance, so it doesnt really get easier than that.
Can you provide more detail on how you've done this?
No configuration beyond setting up the federated provider required.
Keycloak is the upstream project of Red Hat SSO (edit: correct name, thanks snuxoll.)
Running in Kubernetes with RDS Postgres in AWS.
If you do use the Docker images it’s pretty straightforward though.
Past that, customization could be better - not because it doesn’t support it but because many of the SPI’s are poorly documented at best, or totally undocumented at worst. You’ll need to read the code and understand Java EE to do anything not supported out of the box, which, to be fair is a lot - but I’m having to spend far more time looking through code than I’d like to add a Steam login for PCGamingWiki, as an example. Thankfully I’ve dabbled with Java EE before so it’s no big deal to me, but something to consider if you wanna do something simple like add extra profile fields.
EDIT: one major nag I have is that the LDAP integration has an annoying bug related to renaming of users. Keycloak can be configured to use a GUID in an LDAP store as the link between a Keycloak user profile and an LDAP object, but when the username changes it will delete and recreate the account instead of updating the username. This creates a whole new sub identifier in the JWT assertions, which has caused me headaches.
I have a bug on file for this which just recently got updated targeting a fix in 10.0, so hopefully this gets fixed soon.
That said, do you believe it will still be possible to extend Keycloak using the deployment-scanner?
Also, do you happen to have open-source code related to Keycloak and/or custom extensions?
Beside the poor doc, finding more open-source code is one of the best way to learn this.
[1]: https://issues.redhat.com/browse/KEYCLOAK-13068?jql=project%...
I'm hoping this will lead to significantly faster startup times so that my integration tests will run faster.
Even if it wouldn't bundling your keycloak-with-amenities is a 10-minutes job (1. make a pom.xml with keycloak dependency and your stuff 2. mvn package 4. there is no step 3)
It is super heavily based on Wildfly, and if you're not using a tool like docker, it can be kind-of a burden. It runs decently well in standalone mode, but we ended up using the docker container's clustering with Kubernetes service discovery helping to find the other nodes to achieve a clustered deployment.
Outside of that is has been extremely stable, we use Kubernetes deployment mechanism along with a correctly defined readiness check to allow us to seamlessly upgrade, and we've gone from 4.3.0.Final to 7.0.1 in production without any problems. We haven't upgraded to 8 or 9 yet as we're actually working on some new frontend UI changes we wanted to get out the door with the release.
When the first replica restart, Keycloak makes the updates to the database itself. Sometimes rolling back to a previous version can break. They do not hold the reverse of the database version [2].
I believe the reason behind the STS (StatefulSet) is so the cache have the time to spread among the replicas as it get upgraded.
[1]: https://github.com/codecentric/helm-charts/tree/master/chart... [2]: https://www.keycloak.org/docs/9.0/upgrading/
Our actual DB size is pretty small so these are very non-intensive tasks.
I can't imagine any scenario in which you have FIDO keys and admin enrollment and security but I'm prepared to be enlightened.
a) Because the password is assigned first, it has higher priority, so subsequent logins will prompt for password first until the admin manually changes the user's credential ordering to put the WebAuthn (passwordless) token higher. The user's credential priority overrides the order of challenges in the login flow.
b) There is no option to add or replace one of these credentials, or manage credential ordering yourself, in the end-user webapp that does profile editing / password updates.
An admin may be able to reset your account so that you get the first-login experience again and can enroll new credentials.
Nobody should have designed something like this, for WebAuthn in particular the standard is explicit about the desire for multiple tokens. Lots of the design is more complicated so as to support that capability.
https://github.com/ccouzens/keycloak-openapi/tree/master/key...
Hopefully these are useful to other people.
See the parent directory for the tooling I wrote to generate them from Keycloak's HTML documentation.
I wrote a decent Go client library here: https://github.com/airmap/go-keycloak
It's not easy to weigh up all the options. A simple script to generate JWT tokens might even be an option.
Completely incorrect. There's numerous ways you can handle setting a claim in Keycloak, from hardcoded values, simple JavaScript mappers or custom mappers in JVM languages built using the SPI's.
But it’s definitely easier to live with than Active Directory or SecureAuth.
Both suffer on the documentation front, especially useful “cookbook” type of things. Keycloak is impressive, like a lot of things from Red Hat. But ory is worth keeping an eye on. Both assume fluent understanding of terminology.
If you need an integrated identity database out of the box, go for Keycloak today. Comes with OIDC and SAML, both work great. Ory Kratos still requires some manual tinkering.
I'd also love to hear any experiences comparing KeyCloak with commercial providers (Okta, Auth0, FusionAuth).
If you need a lot of customizations then Keycloak is great since it has a really robust architecture for writing extensions. It's also pretty cheap to run so if cost is a major consideration it's definitely worth a look.
FusionAuth is not open source, so if that is a hard requirement, you'll have to skip it.
Customers want to have their own SSO setup or user roles and instead of providing all those functionalities in the app, can we use Keycloak in front and the Customer can manage their own users/permissions via Keycloak?
So in essence:
Customer A: Have 5 users (login / password), 1 admin and 4 regular users -- admin can add or remove users
Customer B: Have an LDAP and would like to authenticate using it
I'm saying "should be" because personally, I have only used single-realm setups in production so far.
Must say I'm a big fan of Keycloak.
We had huge problems modeling multi-tenancy through reals in Keycloak.
Take everything I'm saying with a grain of salt. But, if you are planning to have a lot of customers and realms, do a benchmark by creating a lot of realms and checking if you can use all of them in parallel. YMMV.
That includes SPNEGO (passwordless auth in browser) for those, who are enrolled into domain or have Kerberos tickets.
It has nothing to do with systemd, despite what systemd-phobes think.
(1) Have foo request expanded scope for tokens, including scope for bar. Use that same access token to access bar. For this, I'm concerned that if foo needs to use the access token for a longer time and it expires, then should foo do the refreshing independently of gatekeeper? Is there a way to update gatekeeper with a new token?
(2) Have some way of exchanging the user's token for foo, with a user's token for bar. Can keycloak do this? Can I still use gatekeeper for this?
These are the questions you need to answer before the way to handle anything can be answered. Ultimately, whoever has the session is responsible for renewing the access token - if you're talking to a stateless service that would be the users browser, if you have a server-side session for the app then it would be the server itself.
As far as the access is concerned, avoid token exchange. If foo will always need to talk to bar, then have it request that scope and include it in the tokens.
I use various home made Ansible roles and I find the Keycloak API to be inconsistent.
Eg: Various GET methods that doesn't return complete payload and some endpoints that doesn't save on POST but they do when updating.
That said, it's very hard to keep an idempotency with the actual state of the API.
I haven't yet tested the keycloak-operator [1].
And yes, the keycloak api is inconsistent.
One feature that stands out is for me the social login integration: a few clicks and they just work. Between the downsides, I have to mention the fact that since it's an external tool you need to take care of monitoring, uptimes and upgrades separately from your application.
Recently I started a little side project to create some themes for Keycloak, the original look and feel is very "enterprise" and I thought about creating more modern alternatives that you can install and customize in minutes. I don't know if it's interesting for someone, but in case you are interested you can follow the progress at https://keycloakthemes.com and maybe subscribe to the newsletter to be notified when I release the first theme.
I went with IdentityServer4 on a recent project over Keycloak and Gluu[1] for that reason and because it was in the same stack as the rest of our ecosystem.
[0] See comment from this thread https://news.ycombinator.com/item?id=22871756
IdentityServer certainly has better documentation for its extension points at the moment, but the tradeoff is you have to build everything yourself. Keycloak comes with a built in admin UI, account management UI, TOTP and WebAuthN support, the list goes on. You have to go out of your way to build these or search for a mismash of plugins for IdenityServer to get everything Keycloak provides out of the box.
And while the extension points of Keycloak aren't super well documented, literally all of them are in a dedicated Maven module [0] making it easy to just browse the code.
[0]: https://github.com/keycloak/keycloak/tree/master/server-spi/...
IS4 sits in this weird space where it does work via OAuth/SAML and can work with Windows identity that the browser gives to it, but can't authenticate users against AD with a password.
That said, Keycloak supports Galera clustering and the Infinispan cache can be configured to work in a multi-DC environment - so there's nothing stopping you from Geo-replicating the setup.
Want to replace a legacy openldap installation with something more modern and future proof, but need to keep supporting a couple of old systems that won't go away for a long time.
Note that I haven't set it up myself yet, it's still on my ever-growing list of "tools I have to take a good look at sometime in the future". It does seem like a very good piece of software though.
I've never used it, but if I needed to do something like the GP asked, I'd definitely give it a look.
If it's enough you can plug in any hash algorithm into keycloak.
Generally speaking you never, ever want to pull password hashes out of your LDAP server - and most will fight you tooth and nail when you try.
I was looking into Keycloak last year but eventually gave up because I can't find a friendly/robust enough solution to use source code to manage Keycloak config.
I am curious how do you guys manage staging/production Keycloak instances? Do you just manually trying to keep it the same?
Another question is: Does any company actually use the authorization part of Keycloak? How's the experience?
No real need for Keycloak here, AKS uses Azure AD natively, GCP and AWS can be configured to use SAML straight from Azure AD to handle authentication.
You could use Keycloak though.
did something happen recently that I'm missing out on?
RedHat has some nice software designers - design for extensibility is visible in every product they create. And adhering to standards like the Java EE web framework instead of going the NIH style of Spring. After 2 or 3 major releases the Spring APIs start showing signs of leaky abstractions or outright confusing mess.
Thought I would ask sense I'm working on this right now :)
The Profile SPI in the works hopes to make this much easier, you can track the progress on that on the JBoss JIRA tracker [0].
Whenever you want someone authenticated you redirect the user's browser to Keycloak. Keycloak will redirect the user's browser back to you once authentication has been completed. In the best case scenario you will find a library that integrates with your choice of web framework, provide configuration (i.e. the URL to Keycloak), and the library will do all the heavy lifting for you.
I found Keycloak as a product relatively easy to get started with. But I still don't think I fully understand the authentication landscape with its' many alternatives and their many security implications.
* Getting started with Keycloak: https://robferguson.org/blog/2019/12/24/getting-started-with...
* Angular, OpenID Connect and Keycloak: https://robferguson.org/blog/2019/12/29/angular-openid-conne...
* Angular, OAuth 2.0 and Keycloak: https://robferguson.org/blog/2019/12/31/angular-oauth2-keycl...
* Keycloak, Flowable and OpenLDAP: https://robferguson.org/blog/2020/01/03/keycloak-flowable-an...
* Keycloak Themes - Part 1: https://robferguson.org/blog/2020/04/12/keycloak-themes-part...
Java EE
Ory Hydra only deploys a openid connect provider on top of whatever authentication you want to use. Ory Krato is their new auth system, but still in very early stages.