Right now, only the Elytron-based adapter is available and you can still configure a policy enforcer for your applications.

But once we remove the OIDC adapter completely it won't be available anymore and we need to provide something like what Stian is suggesting.

Looks like Quarkus implementation supports things like http-method-as-scope and policyenforcerconfig. I might take a look at transitioning my project to Quarkus from Spring. https://quarkus.io/guides/security-keycloak-authorization

Are you talking about keycloak-authz-client ?
It seems unrelated to spring. Why not recommend to continue using just that part ?

That library provides the "connection" bits, and an API to interact with the server to obtain permissions and use the Protection API.

But the PEP also has a layer on top of that with the logic to actually process HTTP requests and grant/deny access accordingly.

We can definitely provide some generic library for Java, something easy to integrate using a filter, interceptor, etc.

@pedroigor is there a first version of that generic java library available? What is the timeline here?

Actually, upon reflection, it looks like the client uses its own client id and client secret for Step 5...

And since it's representing a human requesting party, I think it needs to include an OIDC ID token via the "claim_token" and "claim_token_format" parameters...

Without those parameters, I imagine the authorization server would need interaction from the human requesting party to provide claim information. (Alternatively, maybe it use a client redirection to pickup the Keycloak session cookie to fetch these details for itself?)

I'm in the same boat as you. I've been really trying to use Authz for Spring via my keycloak server but stuck trying to create an implementation with the bare bones OAuth2 client.

I was thinking about creating an @PreAuthorize annotation method to check if the user has access to the resource scope. My idea was to put this annotation on different endpoints specifying the scope / resource pair. The method would first check if the current token contains the required authorization. If it does not, then a token request would be made with the scope / resource for an RPT.

The new token should return with the provided info. If it doesn't, then the client doesn't have access. If the new RPT contains the valid authorization info, then replace the old auth token (to try and reduce required requests)

It's really unfortunate that the only solution to policy enforcement rn is using Quarkus. I might check it out.

Looking at the code in the Quarkus plugin I think this is pretty much what they do.

Check whether the token has the resource permissions and request them from keycloak if it doesn't.

Not really, as the internals are going to be kept or even replaced. The deprecation here is related to the capabilities you get from adapters.

@christophenoel There is, but only for Java.

The policy enforcer code [1] was extracted from our adapter code base into a separate dependency.

With that, Java applications are going to be able to use the policy enforcer on any Java-stack (not only those supported by our adapters).

We are working on documentation and how to use it. The documentation should be initially based on how to enable it to Jakarta applications. For instance, using a servlet filter to enforce policies.

[1] https://github.com/keycloak/keycloak/tree/main/authz/policy-enforcer

Yes, I was very happy this morning when I got these news. ! Thanks.

@harshdesai991 Not yet available. But I'm working on some quickstarts, you should see commits arriving there soon.

I'm not 100% sure if we need specific documentation for the policy enforcer but focus on code examples from our quickstart repository. Wdyt?

@pedroigor yeah code examples would be great as well 👍

@pedroigor To get started before releasing of 22 version, can I use the nightly release of Keycloak? Will it have relevant changes related to your policy enforcer change?

Yes, you can. A quickstart is being developed here keycloak/keycloak-quickstarts#396.

@pedroigor I am trying to integrate keycloak-policy-enforcer with Spring Boot 3 application. Looking at your above PR I created oidc.json and policy-enforcer.json in resources folder, than I am trying to get AuthorizationContext in OncePerRequestFilter like below but I am getting the AuthorizationContext as NULL Could you please point me in the right direction to integrate this with Spring Boot application :

@Component
public class KeycloakAuthzFilter extends OncePerRequestFilter {
    private static final Logger LOGGER = LoggerFactory.getLogger(KeycloakAuthzFilter.class);

    @Override
    protected void doFilterInternal(HttpServletRequest request, HttpServletResponse response, FilterChain filterChain) throws ServletException, IOException {
        AuthorizationContext authorizationContext = (AuthorizationContext) request.getAttribute(AuthorizationContext.class.getName());
        if (authorizationContext == null) {
            LOGGER.error("No authorization context found in request.");
            return;
        }
        for (Permission permission : authorizationContext.getPermissions()) {
            LOGGER.info("Resource: {}", permission.getResourceName());
            LOGGER.info("ID: {}", permission.getResourceId());
            LOGGER.info("Scopes: {}", permission.getScopes());
            LOGGER.info("Claims: {}", permission.getClaims());
        }
        filterChain.doFilter(request, response);
    }
}

Yes, See at the bottom of this page: https://www.keycloak.org/2022/03/releases.html

thanks for the info. This is sad though

I had to re-read all the comments and a bit of https://www.keycloak.org/docs/latest/authorization_services/ to try to wrap my head around everything again, but it sounds interesting!

@stianst : it makes sense "leaving the integration for various programming languages and frameworks to the relevant communities". I'm not opposed to writing my own library (I've done it for OIDC in the past using the OIDC spec to guide me), but I'm still trying to wrap my head around UMA and Keycloak's Authorization Services.

Hopefully, when the Java and Node.js libraries are fully ready, I could use them as a basis for a library in another programming language.

Great that you're keeping the node.js adapter for Authorization around, thanks for that.

@minusdavid I wouldn't worry about enabling UMA, at least in the first iteration/version.

The PEP implementation is basically about querying the token endpoint for an access token with permissions inside (granted by the authz service) and mapping those permissions to paths in your application. If the permission for a given path is there, move forward with the request.

Devil is in the details but that is the idea.

The devil is totally in the details haha, but I appreciate the advice! I have a bunch of questions but I figure I should try having a few goes at it first.

What's the best place to ask follow-up questions about authorization services?

A separate discussion should be fine.