Repository navigation
WildFly OIDC adapter deprecation #9815
Replies: 4 comments 8 replies
|
I read through the information at both links but didn't find anything related to how multi-tenancy is handled. Is that something that is still supported or will we need to deploy separate application instances for each customer? |
|
I believe WildFly team is planning to add support for multi-tenancy, or has already added. I'd suggest asking on WildFly forums though as that's the best place to request this being added. |
|
WildFly team has an example for multi-tenancy support, see: |
|
Thanks. I couldn't find anything in the documentation. |
|
For me, it is a bit confusing to understand what exactly is getting deprecated. Current java / node js clients have functions such as "enforce()". It is possible to set scopes and claims in the access tokens which keycloak can then evaluate and grant/deny. To keep the authorization logic in Keycloak (resources, scopes, policies, permissions), we need to map the endpoints of the (java/node/spring) REST API to the scope, claims, and resources in keycloak access tokens, which then keycloak grants or denies. The existing Wildfly client can also directly ask Keycloak for an augmented access token, if a scope or resource is missing in the access token. So the client (webapp) does not need to fetch new access tokens from keycloak each time before accessing a different REST API response. I wonder if this is possible with other open-source OICD clients. As this makes debugging and testing webapps much easier (there are many less 403 in webapp logs due to lacking permissions, because wildfly keycloak adapter, gets the new permissions automatically). I found the mentioned keywords in quarkus.keycloak : But I am not sure how to achieve such fine-grained authorization with other OICD clients. In general, the move feels like starting all over again. All the community knowledge about integrations will be not applicable anymore and we will have to rewrite our webapp/db integrations for different technologies to get the same functionality we had already. This means costs without many benefits which usually management is not happy about. I can see that this will also be a moment to reevaluate the technology stack for companies. "If we have to rewrite everything anyway, let's reevaluate if we can do it easier with other tools". This can be partially mitigated by migration guides and quickstart-examples for the new technologies. |
|
Around fine-grained authorization we will most likely provide a generic Java client that can be leveraged with different containers, and relatively easily be plugged in with a servlet-filter or something like that. I appreciate your comment that this involves work on your end. However, putting it simply we do not have the capacity to both further develop the Keycloak server as well as adapters, and specifically for the WildFly adapter now that WildFly has native OIDC support it makes no sense for us to continue maintaining ours. |
|
For authorization services specifically let's move the conversations around that to #11681 |
|
In theory a JASPIC module would allow for a nice level of integration with different containers. I know older containers had significant bugs and inconsistencies but that seems to have gotten better over the years thanks to Arjan Tijms' work to bring more visibility to the issue. |
|
Hello folks, what about the "keycloak-servlet-filter-adapter" , This one: Thanks for the information |
|
Yes, the OIDC servlet filter is also deprecated |
I have started a seperate discussion on servlet filter adapter here. #11790 |
|
Please take a look at https://www.keycloak.org/2023/03/adapter-deprecation-update.html for the updates to our plans our adapters. In summary for WildFly we are planning on delivering an authorization client library that can be used in combination with Elytron OIDC or Jakarta Security 3.0. |
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Keycloak is deprecating most adapters in the future, for more information see https://www.keycloak.org/2023/03/adapter-deprecation-update.html.
WildFly 25 introduced native support for OpenID Connect with all the features from the Keycloak adapter and more. Migration to the WildFly native OpenID Connect is very easy as the WildFly team has taken great care to make this as simple as a move as possible.
Check out this blog post from Farah Juma for more details.
We are not planning to support WildFly 25 and beyond with the Keycloak WildFly adapter.
All reactions