Quarkus: OIDC adapter has to provide HttpPermissionChecker

[sberyozkin]

Description
Example of the original quarkus-keycloak configuration:

quarkus.keycloak.policy-enforcer.claim-information-point.claims.request-uri={request.relativePath}
quarkus.keycloak.policy-enforcer.claim-information-point.claims.request-method={request.method}
quarkus.keycloak.policy-enforcer.lazy-load-paths=true

quarkus.keycloak.policy-enforcer.paths.1.path=/asset-service/resources/tenants
quarkus.keycloak.policy-enforcer.paths.1.methods.1.method=POST
quarkus.keycloak.policy-enforcer.paths.1.methods.1.scopes=tenants:create

quarkus.keycloak.policy-enforcer.paths.10.path=/asset-service/resources/tenants/{tenantId}
quarkus.keycloak.policy-enforcer.paths.10.methods.1.method=PUT
quarkus.keycloak.policy-enforcer.paths.10.methods.1.scopes=tenant:edit
quarkus.keycloak.policy-enforcer.paths.10.methods.2.method=DELETE
quarkus.keycloak.policy-enforcer.paths.10.methods.2.scopes=tenant:delete
quarkus.keycloak.policy-enforcer.paths.11.path=/asset-service/resources/tenants/{tenantId}/disable
quarkus.keycloak.policy-enforcer.paths.11.methods.1.method=PUT
quarkus.keycloak.policy-enforcer.paths.11.methods.1.scopes=tenant:disable
quarkus.keycloak.policy-enforcer.paths.12.path=/asset-service/resources/tenants/{tenantId}/enable
quarkus.keycloak.policy-enforcer.paths.12.methods.1.method=PUT
quarkus.keycloak.policy-enforcer.paths.12.methods.1.scopes=tenant:enable

@dfranssen:

E.g. Keycloak javascript permission using the request-uri. Our path is like /asset-service/resources/tenants/abc where abc is the tenant name (uriPart[4] in the code below) for which we check the actual authenticated user is part of. In Keycloak we have a group per tenant (e.g. /abc/users) where the user is put into.

var attributes = context.getAttributes();
var httpUri = attributes.getValue('request-uri');
function isInTenantGroup(tenantId) {
    var result = false;
    var wanted = "/" + tenantId + "/users";
    var identity = context.getIdentity();
    var userGroups = identity.getAttributes().getValue('user-groups');
    if (userGroups !== null) {
        for(var i=0; i < userGroups.size(); i++) {
            if(wanted === userGroups.asString(i)) {
                result = true;
                break;
            }
        }
    }
    return result;
}

if (httpUri) {
    var uriParts = httpUri.asString(0).split('/');
    if (isInTenantGroup(uriParts[4])) {
        $evaluation.grant();
    }
}

Implementation ideas
The adapter has to introspect a scope claim (or Keycloak specific claim - in this case we should have a claim name configured to avoid tying the adapter to KC - though we can do it later). PolicyEnforcer configuration group can be introduced if needed

[sberyozkin]

See #4487 about HttpPermissionChecker

[sberyozkin]

@pedroigor FYI. Pedro, is all we need to do here is parse the KC specific scope claim to get it going for @dfranssen ? What are those numbers 1, 10, 12 etc ? May be I can do a PR...

[sberyozkin]

@stuartwdouglas, if we have @RolesAllowed, how would the users configure path/verb, as the configuration in your PR activates the default checker ?
By the way, we can introduce, as part of this issue, or later, @Scope annotation, to support the OIDC-centric experience better...
@stianst FYI as well

[pedroigor]

@sberyozkin, it is not really related with the scope claim. But authorization claim which holds the permissions (for resources and scopes) granted by Keycloak.

In a nutshell, what we need to do is somehow parse this authorization claim and enforce permissions accordingly depending on the resources that were granted and how they are mapped to specific paths in your application.

This is the KC specific feature we talked about (fine-grained/contextual permissions). Although it also has support for UMA specs.

Do we want a separate extension for it ? Or have it within the quarkus-oidc ?

[pedroigor]

@sberyozkin about those numbers. They are the index for each path you are configuring (backed by a list of paths).

[sberyozkin]

@pedroigor OK, thanks. I believe it should work for any IDP, not only Keycloak, at the adapter level we don't really mind I guess where the token is coming from.
Can you please type an example of the KC authorization claim ?
I suppose for a complete UMA we may consider an extension, but for simpler cases we may ship few checkers with the quarkus-oidc

[sberyozkin]

@pedroigor If it is really Keycloak specific then may be we can introduce quarkus-oidc-keycloak (configuration group quarkus.oidc.keycloak) which would only ship KC specific bits.

I reckon we should try to keep generalizing i.e we can have a simple checker which would work with all IDPs which would say only checks scope and/or groups claim and then we can have something like:

quarkus.oidc.permissions.scopes=a,b,c
quarkus.oidc.permissions.scopes.a.method=PUT,DELETE
quarkus.oidc.permissions.scopes.a.paths=path1,path2
# etc for every other scope

This obviously does not match the requirement of @dfranssen. To be honest, I don't see a way for a generic equivalent of the original keycloak.policy-enforcer because it does look like it is very specific to Keycloak (especially the numbers which can likely be nicely mapped in the KC management console but are tricky to understand by just looking at them in the config).
Stian, @stianst Pedro @pedroigor, can you please decide if this is something we absolutely have to support, if yes, then IMHO shipping a new extension, quarkus-oidc-keycloak would be the cleanest way forward, it would only ship HttpPermissionChecker enforcing the original keycloak.policy-enforcer configuration.
But may be you can see how it can be generically enforced at the quarkus-oidc level

Thanks

[pedroigor]

Can you please type an example of the KC authorization claim ?

"authorization": {
    "permissions": [
      {
        "scopes": [
          "profile:view"
        ],
        "rsid": "8e052f06-a543-4b9c-959d-7b59ca99d1f1",
        "rsname": "User Profile Resource"
      }
    ]
  }

The mapping of resources (rsid/rsname) to paths is what makes possible to enforce access accordingly to the resource/path being requested.

The PEP also allows you to enforce access by querying Keycloak in case the token is a regular access token. So that clients don't need beforhand to obtain a token with permissions.

I suppose for a complete UMA we may consider an extension, but for simpler cases we may ship few checkers with the quarkus-oidc

If you make this a priority, I would say that we should start without UMA.

[sberyozkin]

@pedroigor Thanks (though still not sure how the above authorization is mapped to something like what is posted by the user :-) ) and totally agree, lets deal with UMA later on.

But we need to decide what to do for 0.25.0 per my earlier comment.

I'm going offline now, but lets try to finalize tomorrow, may be Stian will have some comments too

Thanks

[pedroigor]

@sberyozkin, sure. Let's sync this.

In a nutshell, we just need to re-use the policy enforcer from the Keycloak Adapter.

[stianst]

As the policy enforcer is very Keycloak specific I think the ideal solution would be to have a quarkus-keycloak-authz extension that depends on quarkus-oidc to do the rest

[sberyozkin]

@pedroigor, @stianst thanks, so we are going with the keycloak specific extension of the oidc adapter, quarkus-keycloak-authz is fine if it will only deal with this policy-enforcer issue, but perhaps there will be more requirements to support something KC specific not related to the actual authorization ? Though quarkus-keycloak-authz can cover all the cases I guess.

[stianst]

@pedroigor would need to look into how feasible it is to create a pure policy enforcement extension, but for OIDC in general we shouldn't need KC specific stuff. Also, I think if we'd have quarkus-keycloak that would confuse folks thinking that they didn't need quarkus-oidc, and that is somehow did more than just authz

[sberyozkin]

@stianst +1, we are all in total agreement that quarkus-oidc is going the generic way now :-). quarkus-keycloak-authz is just fine for me as well if you and Pedro like this name.

[pedroigor]

We are aligned. We should go for a new extension. The name quarkus-keycloak-authz sounds good for me.

@stianst a generic PEP should be possible and it is pretty much possible based on the permission checker Stuart is doing. So that you can have custom checks or interact with a PDP by providing your custom checker implementation.

But yeah, we still need to provide something that works OOTB and that is KC specific (but based on specs).

[sberyozkin]

@pedroigor
If it is based on specs then it should be in quarkus-oidc per our strategy. quarkus-keycloak-authz would keep the old quarkus-keycloak users happy with the KC only specific feature, but once your idea of PEP is realized at some later stage we can may be deprecate quarkus-keycloak-authz given a more generic solution (I guess you were referring to UMA) is available

[sberyozkin]

Hi Pedro, David, copying some comments here:

David: "This is just a thought, but I was thinking there might be a point where it's better for the user to specify things using a builder of some sort (like the router API) rather than having super complex configurations"

Pedro: "Good point. It would certainly provide a better experience. The configuration I mentioned fits better in a JSON format. But in a properties file, it is not so nice. So, what you are proposing is to basically expect a configuration object instance that is produced by the application (using a builder/fluent API provided by the extension) and used by my custom permission checker during initialization? Do we have something similar in any other extension ?"

Sergey: "One possible issue here is that by improving the option for this KC specific configuration we can make it more difficult to eventually migrate users to a generic adapter, especially if they will have something in their code :-). JSON format or a custom builder would be nice, but in this case we are dealing with the users of the original Keycloak adapter who can't just move to the new one yet and already have the configuration prepared. For UMA we can do something really nice with what David and Pedro suggests, perhaps we can prioritize on UMA soon enough for the new users be starting with it. Especially given that quarkus-oidc is expected to work not only with Keycloak"

Sergey: "Pedro, you can probably have something like this, have .runtime.PolicyEnforcer bean and get it initialized in a new extension's deployment processor, and pass it to the runtime recorder where you'd set this PolicyEnforcer instance on the CDI producer which produces a custom HttpPermissionChecker":

@Recorder
public class KeycloakPolicyEnforcerRecorder {

public void init(BeanContainer container, PolicyEnforcer enforcer) {
    KeycloakPECheckerProducer producer = container.instance(KeycloakPECheckerProducer.class);
    producer.initialize(enforcer);

}
@ApplicationScoped
public class KeycloakPECheckerProducer {

private HttpPremissionChecker checker;

void initialize(PolicyEnforcer enforcer) {
    this.checker = new KeycloakPEChecker(enforcer);
}

@Singleton
@Produces
public KeycloakPEChecker checker() {
    return checker;
}

}

[pedroigor]

@stuartwdouglas @sberyozkin In order to plug the policy enforcer, I'm exposing a custom HttpAuthorizer so that I can perform the necessary steps and integration to enforce access using Keycloak Authorization Services. The custom implementation is marked as AlternativePriority.

That would mean replace the default authorizer, which I think is fine. Any thoughts?

[pedroigor]

I'm also not sure whether or not we should rewrite the implementation we have in Keycloak in order to better fit the reactive model in Quarkus. One of the things being that we use Apache HttpClient and would be nice if we could use vertx client instead.

However, it is quite a lot of work (I tried to start something) and error-prone. In addition to having two distinct codebases for the same purposes.

I would like then to reuse as much as possible what we have in Keycloak and adjusting where posible the implementation to properly use the async model provided by Vert.x.

[pedroigor]

@sberyozkin @stuartwdouglas An initial implementation is available here https://github.com/pedroigor/quarkus/tree/issue-4495.

The missing bits are:

• Read config from aplication.properties. I'm going to reuse the code we were using in the old keycloak extension. Do we want to also support keycloak.json ?
• Native (already tried to run on native but I will hold the discussion a little bit ...)
• Write a few more tests to cover most of the scenarios

If you guys think what I have is good enough, I'll try to get those two items done and send a PR.

[stianst]

On Wed, 16 Oct 2019, 23:49 Pedro Igor, [e-mail] wrote:

@sberyozkin https://github.com/sberyozkin @stuartwdouglas
https://github.com/stuartwdouglas An initial implementation is
available here https://github.com/pedroigor/quarkus/tree/issue-4495.

The missing bits are:

• Read config from aplication.properties. I'm going to reuse the code
  we were using in the old keycloak extension. Do we want to also support
  keycloak.json ?

No - we should rather have support for Quarkus application.properties
added to Keycloak admin console.

• Native (already tried to run on native but I will hold the
  discussion a little bit ...)

If you guys think what I have is good enough, I'll try to get those two
items done and send a PR.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/quarkusio/quarkus/issues/4495?email_source=notifications&email_token=AARKSFZJTMQ77C5WOEGPXE3QO6D7BA5CNFSM4I7L73V2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEBOBNRI#issuecomment-542906053,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AARKSF4BUIXAW6AZV25HNBTQO6D7BANCNFSM4I7L73VQ
.

[sberyozkin]

@pedroigor Can you please open a draft PR ? Or if the only bit which is missing is the native support then lets do a non-draft PR ? We can say the initial support for the policy-enforcer is now available, the native support is coming next

[sberyozkin]

@pedroigor quarkus-keycloak-policy-enforcer is a good module name, so we are not going for quarkus-keycloak-authz ?
That is fine, but can we expect something else beyond policy-enforcer that will be related to the KC specific authorization support ? If yes then the name proposed earlier by Stian @stianst and yourself should probably be used, quarkus-keycloak-authz, may be more expanded as some users may find it difficult to read authz, quarkus-keycloak-authorization ?

[stianst]

quarkus-keycloak-policy-enforcer and quarkus-keycloak-authz are both generic names. I'm not to keen on policy-enforcer as there's some ambiguity in it. What types of policies is it enforcing? It's only authz, not general policies, so hence why not just call it -authz.

[pedroigor]

I won't debate about the best name. Either for me it is fine. So, I'll change to quarkus-keycloak-authorization.

Policy Enforcer is a well-known pattern and strongly related to authorization and, more precisely, centralized authorization. Which is pretty much what this extension is all about.

[pedroigor]

@pedroigor Can you please open a draft PR ? Or if the only bit which is missing is the native support then lets do a non-draft PR ? We can say the initial support for the policy-enforcer is now available, the native support is coming next

Sounds good for me. I have implemented the application.properties config and now working with docs. I should have a PR today or on Mon at most.

[pedroigor]

@sberyozkin @stianst , btw a configuration example is like that:

# Configuration file
quarkus.oidc.auth-server-url=${keycloak.url}/realms/quarkus
quarkus.oidc.client-id=quarkus-app
quarkus.oidc.credentials.secret=secret
quarkus.http.cors=true

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

# Defines a global claim to be sent to Keycloak when evaluating permissions for any requesting coming to the application
quarkus.keycloak.policy-enforcer.claim-information-point.claims.request-uri={request.relativePath}
quarkus.keycloak.policy-enforcer.claim-information-point.claims.request-method={request.method}

# Defines a static claim that is only sent to Keycloak when evaluating permissions for a specific path
quarkus.keycloak.policy-enforcer.paths.1.path=/api/permission
quarkus.keycloak.policy-enforcer.paths.1.claim-information-point.claims.static-claim=static-claim

# Defines a claim which value references a request parameter
quarkus.keycloak.policy-enforcer.paths.2.path=/api/permission/claim-protected
quarkus.keycloak.policy-enforcer.paths.2.claim-information-point.claims.grant={request.parameter['grant']}

# Defines a claim which value is based on the response from an external service
quarkus.keycloak.policy-enforcer.paths.3.path=/api/permission/http-response-claim-protected
quarkus.keycloak.policy-enforcer.paths.3.claim-information-point.http.claims.user-name=/userName
quarkus.keycloak.policy-enforcer.paths.3.claim-information-point.http.url=http://localhost:8081/api/users/me
quarkus.keycloak.policy-enforcer.paths.3.claim-information-point.http.method=GET
quarkus.keycloak.policy-enforcer.paths.3.claim-information-point.http.headers.Content-Type=application/x-www-form-urlencoded
quarkus.keycloak.policy-enforcer.paths.3.claim-information-point.http.headers.Authorization=Bearer {keycloak.access_token}

Shall we also replace the policy-enforcer by authorization ?

[dfranssen]

👍

Some questions:

• please make sure that the policyEnforcer url, which is built from the authServerUrl, takes into account the overwritten value from the environment variable QUARKUS_OIDC_AUTH_SERVER_URL or if it is being set via a profile.
• is it still possible to access the KeycloakSecurityContext? (I use it to get the list of permissions (scopes) from its AuthorizationContext in order to know if e.g. the scope tenants:view or tenants:view-detailed is granted. In the latter case more information will be returned). In the previous extension there was a KeycloakSecurityContextProducer
• in some discussions before there was some thoughts about introducing an annotation Scopes in order to avoid verbose resource/method definitions in the application.properties. Is this still a valid option?
• would it be posssible to have also free access to some resources without the need of being logged in or having some required authorization?
• is the oidc or this auth only for rest resources or would there also be some support for websockets or server sent events? Because by specification headers are not supported for both of them when connecting via the browser. In the means of e.g. passing the access_token as a query param which is intercepted in a filter and set to the headers before security kicks in?

[pedroigor]

Some questions:

• is it still possible to access the KeycloakSecurityContext? (I use it to get the list of permissions (scopes) from its AuthorizationContext in order to know if e.g. the scope tenants:view or tenants-view-detailed is granted. In the latter case more information will be returned). In the previous extension there was a KeycloakSecurityContextProducer

Good point. You should have the same behavior as before in regards to being able to inject the KeycloakSecurityContext.

When the policy enforcer kicks in, it may exchange the bearer token with a new token from Keycloak with the granted permissions. We need to push this new token back so you can obtain its claims through Microprofile JWT API. The problem is that authorization happens now after the authentication and the identity is already established. So, in order to avoid more discussions on how to do that based on the current security framework, I would consider MicroProfile JWT API integration as an improvement in future versions.

• in some discussions before there was some thoughts about introducing an annotation Scopes in order to avoid verbose resource/method definitions in the application.properties. Is this still a valid option?

At least for this initial version, I would suggest to not include any annotation. The reason is that it would require thinking a bit more about what we really want to provide in order to improve user experience. For instance, I was thinking about also including a @Claims to map CIPs.

• would it be posssible to have also free access to some resources without the need of being logged in or having some required authorization?

This should be possible by defining:

# Disables policy enforcement for a path
quarkus.keycloak.policy-enforcer.paths.4.path=/api/public
quarkus.keycloak.policy-enforcer.paths.4.enforcement-mode=DISABLED

And make sure the method is not annotated with @RolesAllowed.

• is the oidc or this auth only for rest resources or would there also be some support for websockets or server sent events? Because by specification headers are not supported for both of them when connecting via the browser. In the means of e.g. passing the access_token as a query param which is intercepted in a filter and set to the headers before security kicks in?

The quarkus-oidc relies on the Authorization header. I think WebSocket should be a separated issue ...

[dfranssen]

Thank you for your feedback.

Please make sure that the policyEnforcer url, which is built from the authServerUrl, takes into account the overwritten value from the environment variable QUARKUS_OIDC_AUTH_SERVER_URL or if it is being set via a profile. In my current setup, this seems not to be the case and the default quarkus.keycloak.auth-server-url is being used to build xxx/auth/realms/myrealm/.well-known/uma2-configuration

[pedroigor]

The policy enforcer just uses whatever you defined in keycloak.oidc.auth-server-url. Is that what you mean ?

[dfranssen]

The policy enforcer just uses whatever you defined in keycloak.oidc.auth-server-url. Is that what you mean ?

yes if e.g. in application.properties we have

quarkus.oidc.auth-server-url=http://xxx/auth
%dev.quarkus.oidc.auth-server-url=http://yyy/auth

and set the environment variable QUARKUS_PROFILE=dev or directly overwrite with env var QUARKUS_OIDC_AUTH_SERVER_URL=http://yyy/auth.

I would expect that the policy enforcer url is based on http://yyy/auth, but currently http://xxx/auth/realms/myrealm/.well-known/uma2-configuration is being used. (v0.21 though)

[pedroigor]

It will be intercepted but should be ignored if you have that setting. I have a test using JAX-RS to test a public endpoint. I guess for ws, the behavior should be the same ?

[pedroigor]

@dfranssen it should be able to replace config properties by setting system properties. I guess the behavior is the same when using quarkus.profile.

[pedroigor]

@sberyozkin When running an application JAR everything works fine. But when running in dev mode I get errors due to some classes from commons-logging not in the classpath. Any clue why it works when running the JAR ?

The library is excluded in build-parent.

The same issue shows up when running native (when I first tried). What should we do in this case ? I guess that revert the exclusion of commons-logging is not an option?

FYI, Keycloak uses Apache HTTP Client.

[dfranssen]

Indeed, I had a typo, the public path is working correctly

Op 18 okt. 2019 om 22:04 heeft Pedro Igor [e-mail] het volgende geschreven:


It will be intercepted but should be ignored if you have that setting. I have a test using JAX-RS to test a public endpoint. I guess for ws, the behavior should be the same ?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or unsubscribe.

[sberyozkin]

@pedroigor Hi Pedro, it is pulled in from somewhere in the dev mode I guess, @gsmet - do you know why ?
IMHO, it should not block the PR, we can have a follow up issue (fix for the dev mode, etc).
It all looks good to me, the configuration example.
Please rename the module as you've suggested above (hope Stian @stianst would be OK with it).

@dfranssen FYI, as Pedro said, you will be able to get all the information about the token from JsonWebToken which can be either directly injected or accessed via Quarkus SecurityIdentity - we will be updating the docs. And indeed as Pedro mentioned, we'll definitely proceed with something interesting with new annotations related to the claim-based authorization concept. It is just that the adapter stabilization is more of the immediate priority :-)

Thanks

[dfranssen]

The policy enforcer just uses whatever you defined in keycloak.oidc.auth-server-url. Is that what you mean ?

yes if e.g. in application.properties we have

quarkus.oidc.auth-server-url=http://xxx/auth
%dev.quarkus.oidc.auth-server-url=http://yyy/auth

and set the environment variable QUARKUS_PROFILE=dev or directly overwrite with env var QUARKUS_OIDC_AUTH_SERVER_URL=http://yyy/auth.

I would expect that the policy enforcer url is based on http://yyy/auth, but currently http://xxx/auth/realms/myrealm/.well-known/uma2-configuration is being used. (v0.21 though)

@pedroigor I tried without success with the profile, env variable and system property. I tested with the latest non-breaking version (v0.23.2):

• without pep: the authServerUrl is in the 3 cases correctly replaced (yyy)
• when I activate pep with quarkus.keycloak.policy-enforcer.enable=true, the policyEnforcerUrl is based on the original authServerUrl xxx instead of being the overridden yyy

[gsmet]

What's the status of this one?

[pedroigor]

@gsmet Here is:

• Rename module to quarkus-keycloak-authorization
• Allow injection of KeycloakSecurityContext. I've talked with @stuartwdouglas and currently the request scope is not yet active during auth. I'll be checking that.
• Check the issue mentioned by @dfranssen in regards to profile, env and sys prop configuration values.
• Create follow-up issues for Dev Mode, Native, and Multi-Tenancy (check what quarkus-oidc provides and how it can be used in the context of this extension)

[gsmet]

OK, so it's not 0.26 material, will move it to next release, thanks!

[sberyozkin]

@pedroigor I'm not sure about KeycloakSecurityContext. Lets not tie the users again to the KC API in their user code. What does it offer that JsonWebToken or SecurityIdentiy does not ? If needed we should enhance the latter for example. Thanks

[sberyozkin]

@pedroigor Hi Pedro, re the multi-tenancy, this is also an orthogonal issue (#4448). We have already said KeycloakConfigResolver is no longer supported in the 0.24.0 release notes. The concept of loading the configuration dynamically should work generically (not sure now how to do it without keycloak.json :-), but I can imagine we can use config profiles instead, etc) - can talk more about it at #4448

[pedroigor]

@pedroigor I'm not sure about KeycloakSecurityContext. Lets not tie the users again to the KC API in their user code. What does it offer that JsonWebToken or SecurityIdentiy does not ? If needed we should enhance the latter for example. Thanks

I've considered it just because this is a Keycloak-specific extension and users are already used to it.

No problem if you want to re-use JsonWebToken or SecurityIdentity. However, there is one thing that we would need to do to make the updated token available once permissions are checked by the policy enforcer.

FYI, this enforcer can run in two modes. One mode is all about parsing the granted permission carried by the token. The second mode is exchanging an incoming bearer token with another one with the necessary permissions to access a protected resource. In the second mode, we need to somehow update the security identity with the token that was exchanged. But yeah, the authorizer kicks in after the identity is already established.

The permissions granted by Keycloak are stored in a authorization claim which today we encapsulate through a specific Authorization type that in addition to giving access to the permissions carried by the token it also provides some utility permissions to check whether or not permission was granted as well as to obtain an AuthzClient instance (a client API to the authorization API in Keycloak).

[pedroigor]

@sberyozkin @stuartwdouglas I'm about to send a PR (including quickstart) considering all the suggestions and issues herein suggested.

I'm still not sure about how to proceed with the commons-logging error I mentioned before. The behaviour is quite weird. When running tests, everything works fine (JVM mode) but when running using a separated application (e.g.: following the guide/quickstart) it does not work in JVM mode. To make it happen users would need to include commons-logging in their pom.xml. Probably a not good thing.

Like I mentioned before, removing the library from the list of excluded deps in Quarkus would make things work. But I'm not sure if that is something I'm allowed to do. What do you suggest ?

[sberyozkin]

@pedroigor Hi Pedro, I see, I propose that we discuss this concept, to show which permission was granted as part of some follow up PR, because once the oidc adapter will support UMA, etc, the same kind of utility method check should work as well. We'll add some nice typed methods to TokenCredentail for example.
The most important thing is that we'll have the users able to migrate, but this keycloak adapter is really just about helping them to migrate as opposed to growing in some parallel way with the oidc one :-), Please check if Stian is fine with this interpretation, my understanding was that yes....

The other thing, that 2nd part, the token exchange, that should be eventually done at the quarkus-oidclevel as per our earlier discussions as it is not KC specific ? We can do in the next phase though.
FYI, I'm at Apache Con so may be slow in replying

[pedroigor]

@sberyozkin The part that makes available the granted permissions through the SI is already implemented. I've even added a PermissionChecker so that users can use SI related methods to check whether or a specific permission is granted (if they want to check programmatically).

The exchange part is also working and is a core capability of the extension.

The missing bit now is just this commons-logging issue that I'm not sure how to proceed ...

[sberyozkin]

@pedro, sure, that the KC policy enforcer needs it; but in time we'll have the oidc adapter having a similar requirement, exchange a token (to delegate or impersonate) using the token exchange protocol - the concept has to work with the 3rd party IDPs. At that point we'll most likely want to reuse the code which will be located in the KC extension but without the KC specific API :-)

I propose to open a PR for us to discuss for few days, and then once it makes it - add a follow up PR.
Or just not use KC specific API and Apache HTTP Client - do few simple gets/posts with the API which requires fewer deps ? Actually, it rings a bell, @vsevel had to replace the Apache HTTP client with OK HTTP client as part of the Vault work which is now on master

[vsevel]

some (@starksm64 @gsmet) have argued that rest calls should be done using the default quarkus jax-rs client. I created https://github.com/quarkusio/quarkus/issues/4162 as a result of this feedback.
as far as okhttp is concerned, it seemed smaller than the apache httpclient, and I saw that the fabric8 kubernetes client was already using it.
the new java 11 HTTP Client might offer an alternative at some point, but I suspect quarkus will have to support java 8 for a while, so that might not be an option in the foreseeable future?

[dfranssen]

@pedroigor @sberyozkin I tested this weekend with v0.27.0 and all remarks I have made have been resolved. Thanks a lot!

[pedroigor]

@dfranssen tk u for checking it !