Hi Stian,
Thanks for clarifications, got it. Meanwhile, I've more or less figured out how to build an ad-hoc custom admin resource, maybe this could be interesting for you or other developers.
Setting aside the frontend and role creation issues, the main problem was to obtain HttpHeaders upon resource creation, so that JWS could be extracted. (Surely, we could use a @Context HttpHeaders argument in every service method, but that would lead to unnecessary argument list pollution.)
What I did was to introduce a @Context HttpHeaders private field in HelloResource, and manually perform injection in HelloResourceProvider:
@Override
public Object getResource() {
HelloResource hello = new HelloResource();
ResteasyProviderFactory.getInstance().injectProperties(hello);
hello.setupAuth();
return hello;
}
This is identical to what is done for admin sub-resources in org.keycloak.services.resources.RealmsResource. The question is, why couldn't injection be done in RealmsResource::resolveRealmExtension? Having support for @Context fields injection is very useful, but I don't think custom providers should monkey with Resteasy internals themselves.
Dmitry
Once we introduce a realm admin resource provider I was hoping it would sort out these issues. It's not a high priority for us at the moment though, especially not considering that in the future we want to remove the master realm as well as remove the whoAmI endpoint used by the admin client and instead make it use the token directly.