Authorization Rule not respected

Securing applications
1

Hi,
I would appreciate some help debugging my issues with Keyclok.
While the setup for Authenticating Users works fine and integrating
other IdPs was successful, the Authorization part does not work.

I followed the Documentation in [Authorization Services Guide] that shows how to set up a client
to act as a Authentication Resource Server.
We want to grant access based on Realm Roles and testing the access in the evaluate
tab gives the correct result, some users are granted access and some are not.

However, this does not translate to user access being restricted when trying to
access the actual client.
Does anyone know where to start to debug this?
It seems like the scope URI is not recognised or something such that Authorization
Policies are never evaluated when accessing the client.

Help would be appreciated, I like Keycloak and its extendability but without
working Authorization model it is not an adequate tool for us.

Cheers

2

I’m curious about the details of what you are doing…
Please correct me if I’m wrong.

  1. you obtain a token from Keycloak
  2. you call your service with the token
  3. the service calls Keycloak with the token to get permissions
  4. the policy executes in Keycloak, a permissions payload is built and returned
  5. the service now needs to extract permissions from the payload and check for the required ones

What I understand is that step 4 doesn’t work. The symptom is that the permissions payload is not correct.

Is that it?

3

Hi,
I think I got the idea wrong about Keycloak Authorization.
My idea was to use the policies to restrict access to the client.
But in order to do that I need an additional Authenticator that checks
policies or does the required_role check directly.
Cheers

4

I still don’t understand your flow, or what you call “an additional Authenticator”. You didn’t answer my question.

I guess what you mean is: you still need to check something in your service?

Yes, a service receives a token, but the token has to be checked.
Either the service can introspect the token, so it reads the JWT and checks for what’s inside, or it calls Keycloak.
But Keycloak will not raise an exception or refuse the call for forbidden stuff. It will answer with a payload that contains permissions. Forbidden or authorized permissions, which are scopes and resources.
That is very good, because it means that JWT are issued by Keycloak, consumed by Keycloak, a black box for anyone else, and policies are managed in Keycloak.

Using policies means you have to define your service’s permission model.
Using RBAC in your service means you just read the JWT in the service, but you are also responsible for checking its audience, expiration date, signature, etc.