quarkus-keycloak-authorization will break quarkus-websockets. Why?

[SetoKaiba]

When quarkus.keycloak.policy-enforcer.enable=true is set, the websocket with the path in keycloak authorization will not able to be connect.
The permission of the resource is the same with the websocket. Websocket doesn't support custom header. I think that webSocket doesn't support keycloak security. Why is it affacted? Or does the websocket support security?

[quarkus-bot[bot]]

/cc @pedroigor (keycloak), @sberyozkin (keycloak)

[sberyozkin]

keycloak-authorization requires a verified OIDC token to function

[SetoKaiba]

keycloak-authorization requires a verified OIDC token to function

But I think the websocket does not support bearer token authorization because it doesn't support custom header. How does it verify the authorization for websocket?

[SetoKaiba]

I mean that if authorization is not supported. Why is websocket affacted?
I add a permission for path "/aaa". But it affacts both for rest "/aaa" and websocket "/aaa".
So the websocket will be unable to connect. Because no bearer token in the header since it doesn't support custom headers.
I thought that the websocket "/aaa" should not be affacted.

[pedroigor]

@sberyozkin @sberyozkin Perhaps the policy enforcer should only handle REST requests?

[sberyozkin]

Hey @pedroigor Right, I agree, but users would like to retain the token in the ws channel after the initial request and then have it handled as if it came with http...
@SetoKaiba Custom approach is required, please check Discussions, as I believe a few threads are open.

[sberyozkin]

@SetoKaiba For example, #30427.
However it will be no-trivial to integrate it with the keycloak authorization which is implemented as HTTP sec policy check. Please try to make it work first with OIDC bearer token verification alone

[SetoKaiba]

If I provide a reproduce project and realm settings, can you please have a look what's the problem?
EDIT: My mistake. Just check the below post.

[SetoKaiba]

It seems that I make a mistake. Both REST and WS will not grant when no permission is set.
Previously I just check it without Authorization header. My mistake.

Is there a way to make them all available without permission set with only the resource with permission checked?

[sberyozkin]

The problem is that you do not have WebSockets keeping the token, it is not really related to Keycloak at all.

[sberyozkin]

Please focus on WebSockets first, even without any security at all, make it work such that some custom property can be retained in the WS channel across WS requests. Once you have it working we can discuss how to handle the security token instead of the custom test property. So, please get the basic WS test working first and then we'll move on to its linking with the security system

[SetoKaiba]

No. Let me clarify it. I think it's just a policy enforcer mechanism problem
Because it works the same for REST and WS
The Authorization header for WS is ok and I tested.

It acts:

• No resource, policy and permission.
  • With Authorizaion: Bearer xxx
    • REST(401) and WS(no upgrade) both not available.
  • Without Authorization: Bearer xxx
    • REST and WS both OK and I get anonymous SecurityIdentity
• Resource set for REST and WS. Policy grant client 'test-auth'. Permission combine them.
  • With Authorization: Bearer xxx
    • REST and WS both OK and I can get SecurityIdentity
  • Without Authorization: Bearer xxx
    • REST(401) and WS(no upgrade) both not available.

I expect:

• No resource, policy and permission (or any settings that I can make it default avaiable for both)
  • With Authorizaion: Bearer xxx
    • REST and WS both OK and I can get SecurityIdentity
  • Without Authorization: Bearer xxx
    • REST and WS both OK and I get anonymous SecurityIdentity

[sberyozkin]

Would you mind linking to a WS-only application which confirms you have the custom property retained after the upgrade ?

[sberyozkin]

Also, as I said, keycloak authorization is implemented as HTTP Security policy check, so it can't work with non-HTTP calls, unless some specific integration is done.

[sberyozkin]

I can also suggest that you debug https://github.com/quarkusio/quarkus/blob/main/extensions/keycloak-authorization/runtime/src/main/java/io/quarkus/keycloak/pep/runtime/KeycloakPolicyEnforcerAuthorizer.java#L44 just to see what is going on

[SetoKaiba]

https://github.com/SetoKaiba/reproduce
@sberyozkin Hi. Here's the reproduce project. I use 8880 for reproduce project and 8180 for keycloak. I use fix port. So I run the keycloak docker and import the realm-export.json manually.

docker run -p 8180:8080 -e KEYCLOAK_ADMIN=admin -e KEYCLOAK_ADMIN_PASSWORD=admin quay.io/keycloak/keycloak:20.0.3 start-dev --features=preview

http://localhost:8180/realms/test/account/#/
http://localhost:8880/
user: test
pass: test

1. Login, click 4 buttons and check developer tools.
2. Logout, click 4 buttons and check devloper tools.
3. Enable policy enforcer, login, click 4 buttons and check developer tools.
4. Enable policy enforcer, logout, click 4 buttons and check developer tools.

[SetoKaiba]

I can also suggest that you debug https://github.com/quarkusio/quarkus/blob/main/extensions/keycloak-authorization/runtime/src/main/java/io/quarkus/keycloak/pep/runtime/KeycloakPolicyEnforcerAuthorizer.java#L44 just to see what is going on

Thank you for your instruction.

I found strange thing. Enable policy enforcer.
I access to http://localhost:8880. The apply method is called.
I click the Request REST with Bearer. The apply method is not called. But it just return 401.

[SetoKaiba]

It seems that the realm I export is without user and the client secret is missed. I don't know how to export a full realm config. But you can set it yourself.

[sberyozkin]

@SetoKaiba Your WS code looks fine, thanks. Please confirm that you can also get the identity available in onMessage() which is critical. If that works, then it is great, you have WS and OIDC working. It will be definitely worth documenting, I proposed it to the user who provided a similar solution earlier, but I'll have np documenting it myself.

I found strange thing. Enable policy enforcer....

Lets confirm first onMessage() can access a non-anonymous identity.
I honestly have no idea right now why KC enforcer is not seeing it. Or if https://github.com/quarkusio/quarkus/blob/main/extensions/keycloak-authorization/runtime/src/main/java/io/quarkus/keycloak/pep/runtime/KeycloakPolicyEnforcerAuthorizer.java#L46 is even invoked - which also will have to be fixed (add log messages).

So confirm please onMessage can work with the non-anonymous identity, and add a debug breakpoint in the policy enforcer, it will be much clearer what is going on afterwards

[SetoKaiba]

This setting solved my problem. I originally thought that the enforcement-mode is come from keycloak.

# Enable Policy Enforcement
quarkus.keycloak.policy-enforcer.enable=true
quarkus.keycloak.policy-enforcer.enforcement-mode=permissive

[SetoKaiba]

So does it mean that this settings is not working with quarkus-keycloak-authorization? The enforcement mode must be set by application.properties?

[SetoKaiba]

And also, a final question. How can I do a task for more than 2000ms with request scoped SecurityIdentity, UserInfo or JsonWebToken?
If I make a sub thread, the request scoped stuffs are reporting no active request scope problem.
If I make in main thread, onOpen will tell me that it costs more than 2000ms, and some work is lost.

[sberyozkin]

@SetoKaiba great work, thanks for finding the solution which works.

[SetoKaiba]

Thank you for your help. What about the final 2 questions? Or should I create a new discussion thread?

• The enforcement mode I think that it should the same with the client settings if the enforcement mode is not set explicitly in application.properties. Do you think that it's a bug?
• How can I use SecurityIdentity, UserInfo and JsonWebToken in a sub thread? They're all request scoped beans. This problem is caused by the onOpen method can't take time longer than 2000ms.

[sberyozkin]

The enforcement mode I think that it should the same with the client settings if the enforcement mode is not set explicitly in application.properties. Do you think that it's a bug?

Can you clarify please with the example (CC @pedroigor )

How can I use SecurityIdentity, UserInfo and JsonWebToken in a sub thread? They're all request scoped beans.

Hi @manovotn @mkouba, I recall we were discussing awhile back how to correctly handle the request scope propagation through the diff thread contexts, is it about having smallrye-context-propagation and @ActivateRequestContext ? What are the current recommendations ? thanks

[SetoKaiba]

Can you clarify please with the example (CC @pedroigor )

As my previous post said, I set this to permissive. And according to the debug you instruct about the apply method. I found that the AbstractPolicyEnfocer.authorize method use the Enforcing mode instead of the Permissive settings in the Keycloak -> Clients -> your client -> Authorization -> Settings -> Policy enforcement mode.

[SetoKaiba]

Hi @manovotn @mkouba, I recall we were discussing awhile back how to correctly handle the request scope propagation through the diff thread contexts, is it about having smallrye-context-propagation and @ActivateRequestContext ? What are the current recommendations ? thanks

https://quarkus.io/guides/security-customization#reactive-security
Just check the post below. It seems that it's a bug that WS doesn't support context propagation.

[SetoKaiba]

It seems that I can just use ManagedExecutor directly. The context propagation is working correctly for REST.
But it seems that the context propagation is not working for websocket.

For REST, they all run with with executor-threads. It does propagate the context.


For WS, one run with vert.x-eventloop-thread and one run with executor-thread. It doesn't propogate the context.

[sberyozkin]

@SetoKaiba

It seems that I can just use ManagedExecutor directly. The context propagation is working correctly for REST.
But it seems that the context propagation is not working for websocket.

Makes sense to create a bug (or enhancement) request as I'm not sure the context propagation was meant to support WS calls.
Please try to create a simple reproducer, without the security involved, to simplify the setup

[SetoKaiba]

I'd like to create a bug. But I have no idea that what other request scoped bean can be injected to validate the context propagation failure without security. Maybe I can create a issue first refer this post? And others can provide some effort to validate the context propagation failure.

[SetoKaiba]

#30994
Here's the link for the bug.

[SetoKaiba]

@sberyozkin It seems that no one answers me about the context propagation bug.