Hacker News new | past | comments | ask | show | jobs | submit login
Keycloak: Open-source identity and access management (keycloak.org)
455 points by fanf2 on April 14, 2020 | hide | past | favorite | 122 comments



Keycloak is a great piece of engineering. It's a robust IAM, fully-featured, easy to deploy and integrate with. My opinion is that people should rely on battle-tested 3rd party solution like Keycloak for their authentication and authorization needs.

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


Good to hear that a Clojure wrapper is there. I've been thinking about Keycloak, but I was worried that the login or credentials management UI would be outside of my app (and different). But perhaps there is a way to integrate with it while keeping the UI in-app?


You can theme the Keycloak UI to be similar to your app's one, particularly the login/registration screens so the user experience is very smooth. But you can also define the user/account UI and logic in your app and just delegate the authn and authz data through the Keycloak APIs.


The second option seems interesting! Theming wouldn't help, my app is waaaay different from an old-style themed template (server-side rendering, client-side ClojureScript, websockets, etc).

I will definitely take a look, then.


I have the same setup (re-frame SPA, websocket, etc.), the only page that is themed with Keycloak is the login and password change page, everything else is handled by API calls.

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.


> The second option seems interesting! Theming wouldn't help, my app is waaaay different from an old-style themed template (server-side rendering, client-side ClojureScript, websockets, etc).

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.


Oh interesting, I have been wanting to do something with it and Clojure.


Feel free to ask me anything about Keycloak in the Clojure ecosystem. The README of keycloak-clojure needs some lifting but hopefully you'll find everything you need.


We use this at my company (Amplify) as a single "realm" configuration with Google and and a few other identity providers for "login with X". There's also some fun token exchange possible for any openid connect provider.

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!


The best part is when you start chaining Keycloak instances together. We've had a couple cases where customers have wanted their own identity management, so we use an instance of Keycloak to connect to our central keycloak instances and to their solution of choice (Google, AzureAD, etc), and allows everyone to use their preferred identity platform.


I’m a bit confused...are you federating user management of those customers to their IDP? Or running separate keycloack instances for each of them? Or something else?


they could also just let them run their own keycloak instance and use that as the provider for the realm so customers can more easily debug it themselves.

it doesnt need much maintenance, so it doesnt really get easier than that.


Think it would be using brokering, the instance of Keycloak would be an external identity provider. Each customer would have their own instance of Keycloak that could then be configured to broker their choice of identity provider. I think this might be achievable at the realm level in a smaller scale deployment, i.e., using a separate realm for each customer but still chaining them back to the central realm through brokering, rather than spawning off new instances of Keycloak. Just a thought..


Does it mean that a single user can be bound to more then one User Federation/Identity Provider?

Can you provide more detail on how you've done this?


Keycloak links federated identities to its own user accounts, users can do this manually from the account management UI or it can automatically link them by email when a user signs in with a new IdP.

No configuration beyond setting up the federated provider required.


After Okta rudely told us, a paying customer, to pay extra or leave, we decided to survey alternatives. Four years ago, we found Keycloak and never looked back. It’s stable, customizable, well engineered and relatively easy to work with.


We've been using Keylocak in production as a multi-tenant SSO solution for our service delivery. We've been incredibly impressed with the stability and performance and found it extremely effective.

Keycloak is the upstream project of Red Hat SSO (edit: correct name, thanks snuxoll.)

Running in Kubernetes with RDS Postgres in AWS.


Upstream of Red Hat SSO, Red Hat IdM is the commercial product based on FreeIPA.


Oof! Good catch! Yes Red Hat SSO


I've only played with it, but was kind of put off by how much of the 2FA credential management is only available to admins. It's not like Duo where you can update your own enrolled phones, U2F devices, and defaults. End users would have to ask admins to do all that for them.


Hmm. I'm not sure what you mean. Users by default can use the console to update their 2FA credentials. The only time I have to intervene is when they lose their 2FA as it doesn't really do backup codes. We do require 2FA as a part of our login flows so this is something we're using heavily.


It may be better for TOTP; I was looking at U2F and WebAuthn.


What would admin enrollment even look like for WebAuthn? Do I need to FedEx my FIDO security keys to the company IT security department?

I can't imagine any scenario in which you have FIDO keys and admin enrollment and security but I'm prepared to be enlightened.


You can assign the user a temporary password so that they get prompted to enroll their credential on first login. But:

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.


Blergh. I guess maybe this can be both safe and effective while just being really inconvenient, but my instinct is that on the whole it's just going to be inconvenient without being safe or effective.

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.


Did you build any custom extensions for Keycloak by implementing Keycloak's Service Provider Interfaces? If you are running any custom extensions, what features did you have to add?


Any pitfalls you’ve encountered when implementing?


It’s highly integrated with Wildfly (or JBoss EAP for the commercial product), so if you’re not deploying it with the Docker images expect to have fun dealing with the special hell that is Java application servers - setting up infispan and configuring the database in JNDI at a minimum will require some moderate reading.

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.


Agree on the lack of documentation. But one thing I've found really nice is that the source code is really well structured and readable. Every time the documentation has let me down I've been able to find what I needed by reading the source code. That's one of the great underrated advantages of using open source solutions, you're not completely hamstrung when the docs don't give you what you need.


I would agree that a pain point is the lack of documentation, examples, and googleability of the SPI's. I have spent much longer than I would have expected integrating an existing user database.


It looks like Quarkus is going to be considered for one of the next major release [1].

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%...


Some more scraps of information regarding Keycloak on Quarkus is available at https://www.keycloak.org/2019/10/keycloak-x.

I'm hoping this will lead to significantly faster startup times so that my integration tests will run faster.


> do you believe it will still be possible to extend Keycloak using the deployment-scanner?

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)


The biggest thing we encountered was related actually to our initial deployment with active directory. This made logins slow, but actually found we could remove the requirement for Active Directory.

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.


I'm curious how you manage upgrades. I am in the process of rolling Keycloak out to production now and the only thing I don't quite grok is how to do zero-downtime upgrades. It seems like the upgrade may make backwards-incompatible changes the DB schema. Do you replicate the entire database for the upgraded environment?


When using a K8s cluster with the helm chart [1], it's actually the stateful set that takes care to the update.

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/


We schedule a downtime window during upgrade, but typically see no frontend impact to the core service, SSO for end users. We snapshot the DB for rollback if needed as the migrations are not reversible.

Our actual DB size is pretty small so these are very non-intensive tasks.


May I know how many replicas and CACHE_OWNERS do you have?


We've started using Keycloak as a SSO solution for archlinux.org. if you're interested in helping out with Keycloak on an open source project, send me an email!


What help are you specifically needing?


I have created OpenAPI (Swagger) schemas for Keycloak's admin rest API.

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.


You might want to upstream these. I'm sure people will find this useful.


+1 for Keycloak. It's stable and it works.

I wrote a decent Go client library here: https://github.com/airmap/go-keycloak


I've been meaning to play with this for a while. I'm planning on evaluating how well it works as an authentication layer for Hasura. Hasura looks really nice but would be no good to me without an authentication layer. I found this connector as a stat point https://github.com/httpsOmkar/keycloak-hasura-connector


https://userbase.com is a serverless identity and access management platform that might tie-in well with hasura. One of the caveats is the forgot password feature is tricky: https://userbase.com/docs/faq/


Thanks, that does look really good. I'll look into it. I've also been looking at https://fusionauth.io/.

It's not easy to weigh up all the options. A simple script to generate JWT tokens might even be an option.


I'm in the process of transitioning our production Hasura deployment to use Keycloak. So far things are pretty straightforward.


It works with Hasura out of the box, you just can't set the x-hasura-default-role jwt claim dynamically and thus it has to be hardcoded. I evaluated keycloak with Hasura for our company, but settled on writing my own SSO solution, since my experience wasn't as great as others are describing.


> It works with Hasura out of the box, you just can't set the x-hasura-default-role jwt claim dynamically and thus it has to be hardcoded.

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.


Anyone here using Keycloak for a home setup? I've been considering this v/s https://www.ory.sh/, which is more OIDC focused and can't decide.


I’ve been looking into ory platform recently. It’s all still alpha and beta but pretty impressive. The architecture is much more microservice oriented. Keycloack is one large monolith but easy to deploy with Docker.

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’ve been tempted, but it doesn’t support multilateral SAML federation, which is almost mandatory for higher education, which is 100% of my customer base.

But it’s definitely easier to live with than Active Directory or SecureAuth.


Yup, it’s good, I use it with the recently introduced WebAuthN support although it would be nice if it supported passwordless/usernameless login with resident keys


Keycloak works great, but for home something really simple like dex could also be viable.


Thanks for pointing out Ory. Looks promising.


I found this list of open source SSO providers to be useful in learning about CIAM options: https://gist.github.com/bmaupin/6878fae9abcb63ef43f8ac9b9de8...

I'd also love to hear any experiences comparing KeyCloak with commercial providers (Okta, Auth0, FusionAuth).


We looked at Okta, Auth0 and Cognito when shopping for an identity/auth solution. If you have pretty vanilla requirements then a SaaS solution will probably be easier. Keycloak is not the easiest thing in the world to deploy (although it's pretty straightforward to deploy on k8s using https://github.com/codecentric/helm-charts/tree/master/chart...).

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 has some k8s, helm, docker and openshift examples as well. https://github.com/FusionAuth/fusionauth-containers

FusionAuth is not open source, so if that is a hard requirement, you'll have to skip it.


Since you looked at Okta, Auth0 and Cognita ... which one did you pick?


We went with Keycloak. Both for cost and for extensibility. More than happy with our choice


Can someone confirm if this can be used in a multi-tenant saas app environment?

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 was a heavy user of Keycloak until a year ago and I can only recommend your setup if you are sure that the amount of realms is not growing. Every additional realm uses huge amount of memory in Keycloak. From how I understood the architecture, a lot of components (if not all of them) are initialized per realm.

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.


Absolutely. You can setup multiple realms in Keycloak to isolate tenants from each other, and beyond the built in admin UI you can access all of the configuration over a REST API to build you own admin tools if needed.


This should be possible, since everything you mention are realm-specific settings (i.e. you create one realm per customer), including that a user can be admin in one realm only.

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.


Yeah, it's really easy. You can setup multiple realms and then have completely separate realm admin roles for each. Each realm admin will have their own admin console and login URL


I love keycloak but I was always disappointed it cannot be used as an LDAP server. As many open source products and SaaS support LDAP as authentication/authorization, it would have been perfecy for an internal SSO. Instead of keycloak, I had to rely on GSuite Identity Premium: hood product but gets expensive quickly...


Setting up OpenLDAP or 389ds and integrating Keycloak with it is hardly rocket science - no need to reinvent the wheel.


Setting it up with FreeIPA (which contains 389ds) is a matter of filling up a single form in Keycloak admin.

That includes SPNEGO (passwordless auth in browser) for those, who are enrolled into domain or have Kerberos tickets.


FreeIPA has it's own set of problems. One being basically unrunnable in containers because of weird systemd stuff


FreeIPA is not supported in containers, because it is integration of a bunch of services that need to be on the same machine and each of them has its own idea where to keep state.

It has nothing to do with systemd, despite what systemd-phobes think.


And is somewhat broken and bodged with FreeBSD.


I've run keycloak securing internet facing apps with ~1000 users for years. It's so stable, I usually forget it's even there.


Big fan of keycloak (and gatekeeper!) and looking into this issue now: I have an app (foo) which the user calls through a web frontend. Foo then has to call bar, massage bar's response, then return that to the user. How should I manage tokens that way? So far I have 2 ideas

(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?


Is your web-frontend talking directly to an API? Is there a server-side session, or is it stateless?

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.


What would be the suggested way to automate resources creation?

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].

[1]: https://github.com/keycloak/keycloak-operator


We used the ansible module at work but we had to fork it internally and extend it heavily. I would suggest you try https://github.com/mrparkers/terraform-provider-keycloak instead, because terraform cleans up after itself (it deletes resources that you deleted from code, rather than leaving them behind) and terraform is also much faster, because it auto-parallelizes according to the dependency graph. The terraform provider also seems much better maintained than the ansible module.

And yes, the keycloak api is inconsistent.


Thank you very much. I shared it with the team for a lookup.


My company has been using this and it's not only really easy to integrate but we have found it very stable. No issues and really helped us get to market quickly.


I share the same positive experience I read in this thread about Keycloak. Over the years it saved me a huge amount of time that I would have otherwise spent reinventing the wheel. Many thanks to the development team for building such awesome software.

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.


A happy keycloak user here! Okta wants us to pay per user! Ha, if you're a small outfit with a few hundred users sure, but if you have hundred thousands or millions of users. Nope! We went with keycloak and loving it! We run it in multiple docker containers for resiliency on AWS. Postgres DB on RDS. Bulletproof, zero downtime.


Fusionauth was pretty easy to set up self hosted in a container. Is keycloak better or equivalent if all I want is Multitenant JWTs issued (multiple apps/themes in one instance) and an email confirm / password reset workflow for users? Disclaimer: I’ve contributed to the fusionauth .net core library


Damn ! Keycloak on HN homepage ! We use it in production for years. Such a great tool, we deployed a "as a service" version, with a free offer => https://please-open.it


We use this at my.zerotier.com and it works quite well, though it can be a little heavy.


For the dotnet world you can use and extend https://identityserver4.readthedocs.io/en/latest/


Except it can't federate multiple AD domains out of the box, which is what I needed and got from Keycloak.

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.


IdentityServer is a framework to roll your own IdP, it’s not fully functional out of the box like Keycloak.


It can be easier to extend & customize[0] though.

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

[1] https://www.gluu.org/


I wrote the comment you cited :)

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/...


HUGE fan of Keycloak! It's an outstanding IAM platform. AuthN/AuthZ? Great! SAML? OIDC? Awesome! Token translation??? (SAML->JWT) Incredible! It's really a delight to work with. If I had one item on my wishlist it would be support for non-SQL datastores. It hums along on our PostgreSQL instance with no problem. We'd love to be able to easily geolocate it as part of our AWS infrastructure using global DynamoDB tables for data storage. That would greatly improve the login experience for our users as they are located all over the world.


Identity solutions cannot tolerate eventual consistency, if a user changes their password it MUST be replicated everywhere immediately, if an offline token is revoked it MUST stop working everywhere. DynamoDB is not an appropriate tool for the job here.

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.


Can someone recommend a product (open source) that supports: * ldap * multiple password hashes per person, or some other way to keep different hash-functions of the password ( ldap supports this) * saml/shibboleth or openid connect (preferably both) * export all users and password hashes (I guess ldap supports this natively)

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.


If you're really married to the idea of "keep different hash-functions of the password ( ldap supports this)" then I think you are going to have a tough time without really digging into candidate products' customization hooks or considering some manner of virtual directory. IME maintaining multiple password hashes is not at all a common LDAP server feature. Many products will stand in your way of exporting password hashes (just try and wrest this info from Active Directory or Auth0) and you may not be able to control the hash algorithm besides.


I've been considering setting up a Gluu [1] instance for some of my services. It supposedly supports LDAP as well as OpenID and Oauth2 for authentication as well as RADIUS. From what I can tell, this would fit your use case perfectly fine. It's available as open source software but the company behind it is selling it as well in case you'd like a support contract.

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.

[1] https://www.gluu.org/


Just want to say that I've met the lead developer of Gluu randomly at a gitlab hackathon / party in portland. It seems like they've got a really nice product and he was extremely knowledgeable along with very likable.

I've never used it, but if I needed to do something like the GP asked, I'd definitely give it a look.


Keep ldap as backend and use Keycloak for saml, oidc, user-facing console etc. Openldap is not going anywhere and keeping multiple hashes is not a commn feature.

If it's enough you can plug in any hash algorithm into keycloak.


When it comes to LDAP integration keycloak doesn't even store the password hashes itself, it sends them straight to the LDAP server to be hashed on both update and login.

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.


This post [0] persuaded me that I need multiple SAML IDP signing keys to prevent badly behaved third party apps from accepting every user authentication as an authorization. Keycloak supports this configuration, but can anyone comment on how reasonable this is from an ops standpoint? Is it difficult to configure this way? Is it harder to back up?

[0] https://news.ycombinator.com/item?id=22739626


I might be late to this thread. sad :(

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?


Can keycloak let me integrate different k8s clusters running in Azure/Google/AWS with i.e.: Azure AD ? All our users have accounts in Azure AD but we would like to let them use k8s clusters running in different cloud providers without maintaining user accounts there. Is it possible with keycloak ?


> Can keycloak let me integrate different k8s clusters running in Azure/Google/AWS with i.e.: Azure AD ? All our users have accounts in Azure AD but we would like to let them use k8s clusters running in different cloud providers without maintaining user accounts there. Is it possible with keycloak ?

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.


I haven’t looked at this in years (after it was taken over by RedHat). Can someone comment on using Keycloak within a .NET application (which would be a service provider) for SSO with SAML? Does it have easy to use libraries that make application development easier to work with a configured IdP?


Key cloak is pretty awesome. So far it is the only authentication mechanism that we have provided for our open source Dev tool at https://github.com/zubairq/pilot


Does anyone here have experience of miniOrange? What do you think of Keycloak compared to miniOrange? I see it in many places such as JIRA marketplace, WordPress plugins and they always have 5-star ratings. They have their own IdP server too.


How is their support for WebAuthn/FIDO 2 by now? Anybody know?



It seems like a lot of people have seen the light now and are evaluating Keycloak even though it has been around for so long.

did something happen recently that I'm missing out on?


Microservices and api management gets more popular. (and the need for jwt/oauth) since redhat is generally trusted. It is basically the only option if you want to use it.


Hmmm, I thought something happened recently or it's just confirmation bias from my end cause I've been seeing a little too much lately.

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.


Does anyone know if the export functionality works between versions? I'm guessing no.

Thought I would ask sense I'm working on this right now :)


It it easy to save along the user information like companies, contracts and so on?


Simple attributes can be added easily (it's as simple as adding form fields with an id of `user.attribute.company`), but anything requiring access restrictions (only an admin can update, for example) will require custom development.

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].

[0]: https://issues.redhat.com/browse/KEYCLOAK-2966


Could someone please ELI-5 what Keycloak is, and how it fits in a SaaS app?


Keycloak is an authentication portal that sits in front of other applications thereby freeing those applications from the burden of implementing login forms and secure password storage.


Regarding a SaaS application. Let's say you're a SaaS provider and you're selling your service to a big organization. In addition to providing login forms Keycloak also implements the SAML and OpenID Connect standards which means that employees of the big organization can be single signed on from their office computers.


"that sits in front of " does that denote that miminal refactor / re-architecture is needed for a rest based application, trying to get an idea of how easy it is to start using keycloak?


Some Keycloak-related tutorial style posts:

* 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...


By sits in front of I mean that it's a completely separate web application rather than a framework, library or proxy that is somehow bundled with your application.

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.


Keycloak is basically like opensource Okta.


This is some well crafted software indeed, and extendable.

Java EE


How does this compare to Hydra?


Keycloak is basically the entire Ory ecosystem rolled into one big software, along with a management interface and login.

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.


Ah thank you for the well explained response. So does Keycloak have any tools to build an identity provider?




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: