OIDC adapter has to provide HttpPermissionChecker

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]

@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

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