Live data from Hacker News

Keycloak: Open-source identity and access management

keycloak.org

111–120 of 124 posts

Re: Keycloak: Open-source identity and access management

#112

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 i…

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.

Re: Keycloak: Open-source identity and access management

#113
post #10

Earlier quoted context omitted.

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…

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…

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

Re: Keycloak: Open-source identity and access management

#115
post #39

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, b…

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.

Re: Keycloak: Open-source identity and access management

#116

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…

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.

Re: Keycloak: Open-source identity and access management

#117
post #115
post #39

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, b…

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.

Re: Keycloak: Open-source identity and access management

#118
post #102

Earlier quoted context omitted.

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.

Re: Keycloak: Open-source identity and access management

#119
post #73

Earlier quoted context omitted.

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.

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

Re: Keycloak: Open-source identity and access management

#120

Earlier quoted context omitted.

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 t…

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.

Post reply on HN