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
We'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/.
You can try it out on the latest Keycloak by passing the --features=admin2 flag on startup.
> 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!".
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)
We'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.
I'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.
For 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.
> 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.
Can 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).
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.
My company used Keycloak for a long time (I'm not there any more) and I agree with everyone here, it works great, but it's hard to understand unless you already know oauth/oidc, and it is a huge binary.
While Keycloak is a great out-of-the-box solution, my #1 complaint at the time was how heavyweight it was, which was a burden for development, followed closely by its packaging as a J2EE app and bundling with Wildfly (at the time).
This meant we needed to know not only about Keycloak itself, but also about Wildfly's special quirks, the clustering system (Infinispan??), Java and Docker.
Now it's packaged with Quarkus, which is another dependency to learn about, and to be honest despite the quality of the finished product, all those dependencies have become pretty off-putting.
So while I can recommend Keycloak's functionality, if you're not already deploying Java apps as part of your job, I suspect it will present a pretty serious administrative burden to deploy into serious production.
For me this is all kind of opaque, apart from a theme put into a folder and some Environment Variables set i don't touch anything in Keycloak, first had no requirement to consider it and second very likely would be doing something maybe not best practice i.e oidc, oauth based.
Its the only java app we run in stack, but doesn't matter to me in Docker and within Windows we run a portable java from a subfolder of keycloak so not System wide in Path
Was working at a Java shop once which used Keycloak as a central IAM solution. As an FE Dev, I was tasked to customize/style the login-page provided by Keycloak, and quickly faced what you described: Pretty heavily Java-based, even to edit HTML templates I had to recompile using a full blown Java/JVM stack.
As an FE dev without Java background, this became pretty difficult. But once we finished that with the help of some of the BE Java devs, it ran (and still runs) quite stable and also the KeycloakJS adapter I integrated was alright without much surprises.
We tried using keycloak in a startup where I worked. It needed a loooooooot of memory and was very slow to start. It probably needed some JVM tuning, but we were just deploying as a stateful set (for the postgres). The docker images were also huge.
We had to use another FOSS project called Gatekeeper as an authentication software along with keycloak, which got obsoleted and replaced with a different project (lukedo proxy or some such).
The community support was also relatively not that active like other FOSS project that we used (for other areas of the stack). Overall, the experience was not so great that we decided to ditch both keycloak and gatekeeper. This was about a couple of years back. Not sure what the current status is.
Some other alternatives that we wanted to try were from the Ory project (Kratos etc.) But we just went with some proprietary AUTH solution in our startup.
We have been using it for 6-7 years now. Have been able to run very stable and integrated a lot of external IdP's to offer proper SSO on mulitple of our software stacks. Added a lot of other open source pieces of software we run for our backoffice needs (hashi vault, adminbro, etc.). So far very happy with it. Running in clustered mode without issues and as such little issues with the startup times. It probably helps that we have a solid background in Java based development and deployment and are less worried about the amount of memory it uses for the full suite.
In my experience, Keycloak is best treated as a "pet" in the "pet v.s. cattle" spectrum. It takes a while to warm up, so you don't want to be constantly restarting it. I deployed it out-of-sync with the main application deployments.
As an open source option, it's quite powerful and full-featured. It's also quite configurable.
If I had one feature ask, it's that it doesn't play well with infrastructure-as-code ideas. While you can load a new realm from a JSON, it's harder to keep changes synced after that.
Have used and brought keycloak into many companies over the years as a solution. Steep learning curve a little. But it essentially works as designed either as the IDP (rare in my exp) or as a IAM broker more common.
Big companies need it because their hands are tied to old and inflexible vendor's APIs. However they can with some effort craft a branded and modern UI/UX. Backend works with just about anything old Auth related whilst supporting a newer modern Auth schemes.
I am surprised IBM has not made RHEL ruin it yet.
To say IBM is a slightly better steward of their open source efforts than Oracle never leaves one with much comfort.
RedHat never needed anyone's help to ruin things. Their solutions are poorly designed bloated crap that "can get the job done" if you run them within a RedHat platform and don't mind banging your head against a brick wall. Just because they're open source darlings doesn't mean we can't call a spade a spade.
The secret to making keycloak UI/UX good is to disregard the account console and build your own with the new accounts API (which the accounts2 console also uses).
Also, if you just use one broker you can skip the login experience entirely.
Using Keycloak for all authentication both in the cloud under Linux and within Windows Enterprise Environments. Use it for SSO for Node-RED, Grafana, Aspnet & VueJS apps. Was fairly easy to move from Auth0.
I have a few services on my family server (say, Gitea, Grafana, finance tracking app etc.). I'd like to have a SSO but also limit which users can use which services (e.g. my significant other can use Grafana but no Gitea).
Is integrating above services with Keycloak enough? Or would I need another components? Or maybe I've got it wrong and should reconsider the architecture?
It will definitely work - Keycloak can provide its own user database, or it can use external one, as well as do some crazier things that go outside of the scope you mentioned.
In simplest setup (non-HA, local user database), you would create users inside Keycloak, assign them to different groups, then create applications (which handle configuration for individual applications like grafana and gitea) and create rules that specify that only users that belong to specific group can login to specific application.
You can also allow linking multiple external SSOs this way to single keycloak identity, and even include login through kerberos5 or client certificates.
I've integrated keycloak for SSO in our apps, we have a one-to-one mapping between keycloak realms and the tenants in our apps, works great and it can glue together many disparate IdP/auth solutions: onelogin, LDAP/AD, etc. At one moment we needed to implement a custom OTP method, so we developed a plugin by implementing a simple SPI (the auth flow is configurable).
It is a very stable piece of software, we have a combination of Terraform+ansible scripts to deploy it, and once it is done we forget about it until we need to upgrade the version using the same scripts. The biggest drawback IMHO is the documentation quality ...
As others mentioned, Keycloak is a good choice if you need a self-hosted IAM solution and are familiar with Java development.
If you don't need selfhosted, I can recommend using Amazon AWS Cognito as a OAuth2/IAM solution - it is included in the free tier for up to 50.000 MAUs, plus the signup/lost password mails etc. are sent through Amazon SES, which heavily increases the inboxing rate. You could always transition later to a self-hosted solution like keycloak. Given both are OAuth2, that transition should be smooth.
Recently deployed Keycloak as a front end to hide legacy auth in our org and put OAuth in front of it. Despite the apparent complexity under the hood, it works great and no complaints so far. By and large, it just does what it says on the tin and works.
Is Keycloak a good option if I want to setup a SAML Service Provider using user records from my own MySQL database? I've looked at Okta and Keycloak and it's not really obvious to whether I'm supposed to give up my User table and let the auth system handle it, or whether the user data ends up being spread between my DB and the auth system (I think that's how Okta would be implemented).
I know I could roll my own with PassportJS or something, but I'd like all the nice Okta stuff (MFA, password policies, SAML SSO, maybe federation) but integrated with my existing DB. Or is that just too much to ask?
Are you asking if you can use Keycloak with your own user table? Typically these identity providers want to own the user, so would expect you to port the user info, including password hashes, into them.
If you have data that is user related but not auth related (application specific data), I've seen a few patterns:
* Push it all into the auth provider. Not sure about keycloak, but some providers have the ability to store arbitrary data (a blob, basically) about a user.
* Create a table in your database with an identifier provided by Keycloak, preferably an immutable one. Then when a user logs in, you can find their identifier, then look up the application specific data.
If you want to have all PII in one place, the former option is best. If you want to maximize your flexibility, the latter is what I'd suggest.
If you want to keep the user data in your database, I'd look at a library (as you suggest). It's a different class of solution than a standalone auth provider like Keycloak.
Transitioning a preexisting web stack in our corporate network from Identity Server to Keycloak has been my extremely rough intro to the world of auth. I would say I’m almost there, but have one issue holding me up. We have a few different data enclaves, including one that requires users to sign an NDA and be added to an AD group. I’ve been searching high and low to see if Keycloak has a simple flag to say “don’t let anyone in that isn’t a member of this AD group”. Does that exist or do I have to create groups in Keycloak itself and add users manually?
Keycloak is a great piece of software if you have to authenticate against AD (on prem, not Azure AD). It's the best way to isolate all the crap like "user accounts live in this OU, but admin accounts live only in that OU. Oh, and we also have another domain where contractors live in the same OUs. And the groups that map to application roles are the same, but live in differently named OUs" and provide a simple OAuth 2.0/OIDC authentication/authorization interface to all this mess.
My biggest issue in the version I was evaluating:
Some service providers use “email” as username (in fact many do.)
Keycloak doesn’t make it easy to prohibit users from changing their own email, making it trivial to impersonate someone else and gain access one shouldn’t have.
Keycloak actually makes it very easy now, assuming you have account-api and account2 feature flags set (default these days). You remove "manage-account" inside the "account" client from the default roles. Do mind this breaks the account console for those users (which is what you probably want anyway).
So you could only allow an email change if the user proved they owned the new email account by clicking a link or entering a code sent to that account?
Seems like a natural option.
Of course, allowing you to disallow email changes seems pretty reasonable too.
For those that may not be aware, Keycloak is the upstream of Red Hat's SSO solution "Red Hat Single Sign-On", so there is a lot of weight behind it's development.
I'm building something with it currently and it's quite nice, especially if you are already familiar with spring security. Documentation is quite sparse tho.
I've integrated keycloak for SSO between several self hosted apps and boy I had no idea what I was doing but copy paste config from left and right from various sites which worked in the end but does SSO have to be this complicated?
Can someone recommend a simpler solution to integrate SSO with online tools (like NextCloud, Discourse, Wiki.js, Gitea etc)?
I've used many solutions, even built my own in the end. Problem is that there's no software that can make SSO easy to understand if you don't know everything about SSO to begin with.
SSO is not that complicated to work with, the docs are just stupidly difficult to read and the point of the whole process is rarely explained. Learning how without knowing why is nearly impossible.
[+] [-] schipplock|3 years ago|reply
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.
ok, still big :).Beware: they aren't using Docker Hub anymore. Newer versions are on Quay only (https://quay.io/repository/keycloak/keycloak).
I'm happy with Keycloak. Also nice folks around Keycloak.
[+] [-] jonkoops|3 years ago|reply
You can try it out on the latest Keycloak by passing the --features=admin2 flag on startup.
[+] [-] paulmd|3 years ago|reply
> 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
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)
[+] [-] password4321|3 years ago|reply
This is one area where incentives don't align correctly for open source projects that offer commercial support.
[+] [-] chrisoverzero|3 years ago|reply
Oh, right, Quaycloak.
[+] [-] mooreds|3 years ago|reply
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/0...
[+] [-] imglorp|3 years ago|reply
Very happy with KC otherwise. We make heavy use of its nice API to create providers and clients at install time.
[+] [-] johnmarcus|3 years ago|reply
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.
[+] [-] erwincoumans|3 years ago|reply
>> 562MB
Curious, why is the Quay image/container so large? Is there a way to list the contents without downloading it?
[+] [-] tamarok|3 years ago|reply
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.
[+] [-] Perseids|3 years ago|reply
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
[+] [-] yrro|3 years ago|reply
[+] [-] sascha_sl|3 years ago|reply
https://www.keycloak.org/server/containers
[+] [-] 0xbadcafebee|3 years ago|reply
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.
[+] [-] doctor_eval|3 years ago|reply
While Keycloak is a great out-of-the-box solution, my #1 complaint at the time was how heavyweight it was, which was a burden for development, followed closely by its packaging as a J2EE app and bundling with Wildfly (at the time).
This meant we needed to know not only about Keycloak itself, but also about Wildfly's special quirks, the clustering system (Infinispan??), Java and Docker.
Now it's packaged with Quarkus, which is another dependency to learn about, and to be honest despite the quality of the finished product, all those dependencies have become pretty off-putting.
So while I can recommend Keycloak's functionality, if you're not already deploying Java apps as part of your job, I suspect it will present a pretty serious administrative burden to deploy into serious production.
[+] [-] maxbaines|3 years ago|reply
Its the only java app we run in stack, but doesn't matter to me in Docker and within Windows we run a portable java from a subfolder of keycloak so not System wide in Path
[+] [-] ffo|3 years ago|reply
If you are intrigued into the differences, you can read some of them here [2]
Oh and judging from your username: it could be interesting to you... because we use eventsourcing and cqrs ;-)
Disclaimer: I am one of the authors
1. https://github.com/zitadel/zitadel/
2. https://zitadel.ch/blog/zitadel-vs-keycloak
[+] [-] littlecranky67|3 years ago|reply
As an FE dev without Java background, this became pretty difficult. But once we finished that with the help of some of the BE Java devs, it ran (and still runs) quite stable and also the KeycloakJS adapter I integrated was alright without much surprises.
[+] [-] jbaczuk|3 years ago|reply
[+] [-] psankar|3 years ago|reply
We had to use another FOSS project called Gatekeeper as an authentication software along with keycloak, which got obsoleted and replaced with a different project (lukedo proxy or some such).
The community support was also relatively not that active like other FOSS project that we used (for other areas of the stack). Overall, the experience was not so great that we decided to ditch both keycloak and gatekeeper. This was about a couple of years back. Not sure what the current status is.
Some other alternatives that we wanted to try were from the Ory project (Kratos etc.) But we just went with some proprietary AUTH solution in our startup.
[+] [-] nird|3 years ago|reply
[+] [-] sz4kerto|3 years ago|reply
It's reliable, flexible and actively developed, so not a bad choice as a self-hosted IAM solution.
[+] [-] RandomBK|3 years ago|reply
As an open source option, it's quite powerful and full-featured. It's also quite configurable.
If I had one feature ask, it's that it doesn't play well with infrastructure-as-code ideas. While you can load a new realm from a JSON, it's harder to keep changes synced after that.
[+] [-] Datagenerator|3 years ago|reply
[+] [-] sirmike_|3 years ago|reply
Big companies need it because their hands are tied to old and inflexible vendor's APIs. However they can with some effort craft a branded and modern UI/UX. Backend works with just about anything old Auth related whilst supporting a newer modern Auth schemes.
I am surprised IBM has not made RHEL ruin it yet.
To say IBM is a slightly better steward of their open source efforts than Oracle never leaves one with much comfort.
[+] [-] 0xbadcafebee|3 years ago|reply
[+] [-] sascha_sl|3 years ago|reply
Also, if you just use one broker you can skip the login experience entirely.
[+] [-] whazor|3 years ago|reply
The biggest benefit is that Authentik supports Forward Auth out of box. This means that you might not need oauth2proxy.
[+] [-] maxbaines|3 years ago|reply
[+] [-] Loic|3 years ago|reply
[0]: https://github.com/greenpau/caddy-security
[+] [-] n3t|3 years ago|reply
I have a few services on my family server (say, Gitea, Grafana, finance tracking app etc.). I'd like to have a SSO but also limit which users can use which services (e.g. my significant other can use Grafana but no Gitea).
Is integrating above services with Keycloak enough? Or would I need another components? Or maybe I've got it wrong and should reconsider the architecture?
[+] [-] mooreds|3 years ago|reply
The biggest hurdle I see is do all of your apps support SAML or OAuth/OIDC for authentication/authorization? The SSO tax is a real thing.
[+] [-] p_l|3 years ago|reply
In simplest setup (non-HA, local user database), you would create users inside Keycloak, assign them to different groups, then create applications (which handle configuration for individual applications like grafana and gitea) and create rules that specify that only users that belong to specific group can login to specific application.
You can also allow linking multiple external SSOs this way to single keycloak identity, and even include login through kerberos5 or client certificates.
[+] [-] fjni|3 years ago|reply
[+] [-] JacobiX|3 years ago|reply
[+] [-] littlecranky67|3 years ago|reply
If you don't need selfhosted, I can recommend using Amazon AWS Cognito as a OAuth2/IAM solution - it is included in the free tier for up to 50.000 MAUs, plus the signup/lost password mails etc. are sent through Amazon SES, which heavily increases the inboxing rate. You could always transition later to a self-hosted solution like keycloak. Given both are OAuth2, that transition should be smooth.
[+] [-] bfm|3 years ago|reply
[+] [-] spacemanmatt|3 years ago|reply
I like a well-disciplined stack and Keycloak is a star. And that's huge considering my other big players are Vert.x and PostgreSQL.
[+] [-] zmmmmm|3 years ago|reply
[+] [-] vosper|3 years ago|reply
I know I could roll my own with PassportJS or something, but I'd like all the nice Okta stuff (MFA, password policies, SAML SSO, maybe federation) but integrated with my existing DB. Or is that just too much to ask?
[+] [-] mooreds|3 years ago|reply
If you have data that is user related but not auth related (application specific data), I've seen a few patterns:
* Push it all into the auth provider. Not sure about keycloak, but some providers have the ability to store arbitrary data (a blob, basically) about a user.
* Create a table in your database with an identifier provided by Keycloak, preferably an immutable one. Then when a user logs in, you can find their identifier, then look up the application specific data.
If you want to have all PII in one place, the former option is best. If you want to maximize your flexibility, the latter is what I'd suggest.
If you want to keep the user data in your database, I'd look at a library (as you suggest). It's a different class of solution than a standalone auth provider like Keycloak.
[+] [-] navbaker|3 years ago|reply
[+] [-] orthoxerox|3 years ago|reply
[+] [-] fjni|3 years ago|reply
https://keycloak.discourse.group/t/hide-disable-email-change...
[+] [-] sascha_sl|3 years ago|reply
[+] [-] mooreds|3 years ago|reply
So you could only allow an email change if the user proved they owned the new email account by clicking a link or entering a code sent to that account?
Seems like a natural option.
Of course, allowing you to disallow email changes seems pretty reasonable too.
[+] [-] spicyusername|3 years ago|reply
[+] [-] jcroll|3 years ago|reply
I'm building something with it currently and it's quite nice, especially if you are already familiar with spring security. Documentation is quite sparse tho.
[+] [-] mekster|3 years ago|reply
Can someone recommend a simpler solution to integrate SSO with online tools (like NextCloud, Discourse, Wiki.js, Gitea etc)?
Does anyone have experience with Authentik?
[+] [-] zmxz|3 years ago|reply
SSO is not that complicated to work with, the docs are just stupidly difficult to read and the point of the whole process is rarely explained. Learning how without knowing why is nearly impossible.