Add HTTP Permission Layer

[stuartwdouglas]

There should be a generic interface that can be implemented to managed HTTP path permissions, that decide if a given SecurityIdentity can access a provided path+method combo.

By default this should support:

• Servlet web.xml mappings, so even if a security constraint is defined in web.xml and the target of the request is not a Servlet the constraint still takes effect.
• application.properties mappings, a simple way to restrict access to paths based on application.properties.

This will also support user defined constraints by allowing the user to implement an interface with a CDI bean.

[sberyozkin]

@stuartwdouglas and as you suggested, lets have it pluggable so that the OIDC adapter can provide its own UMA/etc mechanism, @pedroigor FYI

[dfranssen]

Currently we have different microservices with similar application.properties as below. Authorization is externalised in Keycloak with policies, permissions and scopes (see Keycloak doc).
With this approach there are no explicit role checks in the different rest endpoints and fine-grained authorization is externalized.

With the latest changes in Quarkus (v0.24) it seems that the keycloak extension is renamed to oidc and the specific Keycloak functionality as policyEnforcer has been removed. This is a major issue as our security approach is now completely obsolete once we update the quarkus version.

Is it possible to keep the keycloak extension next to the oidc one until it has been clarified how to move forward with this issue as it is labeled version 1.0?
FYI @sberyozkin @pedroigor @gsmet

quarkus.keycloak.realm=my-realm
quarkus.keycloak.auth-server-url=http://localhost:8081/auth
quarkus.keycloak.resource=assets-resource-server
quarkus.keycloak.credentials.secret=my-secret

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

[sberyozkin]

@dfranssen can you please clarify, is tenant:enable coming from a scope claim ?

[sberyozkin]

@dfranssen we will try to get an OIDC policy-enforcer for 0.25.0. apologies for the headaches with the migration...

[dfranssen]

@dfranssen can you please clarify, is tenant:enable coming from a scope claim ?

Not sure if it are claims, but more info on scopes in Keycloak.

Please also have a look at #4376 as info is now on different issues

[sberyozkin]

@dfranssen I've put all your comments related to the policy-enforcer to #4495, lets work there

[n1hility]

#4555