Hi Anton, Please mind that in order to run the domainextension example under KC "admin-cli" client scope, see my previous posting here. Other answers inline. В Mon, 27/11/2017 в 09:30 +1100, Anton Mazkovoi пишет: If you're intended to deploy via standalone/deployments, you'll need to define your deps in META-INF/jboss-deployment-structure.xml, like here: https://github.com/dteleguin/beercloak/blob/14da8578310f2d257bdc1b059a8 d355343174180/src/main/resources/META-INF/jboss-deployment- structure.xml You should know that if your plugin contains an EntityProvider and custom JPA entities, you won't be able to hot (re)deploy your code (that means, onto a running Keycloak instance), see KEYCLOAK-5782 for more info. Another option is to deploy your provider as a JBoss module, exactly as described in the README for domain-extension example. In this case, you won't need META-INF/jboss-deployment-structure.xml. I'm afraid not. I myself would be happy to see some declarative way to secure custom REST endpoints, but that would be possible only upon the introduction of the hypothetical Admin REST Resource SPI, which is unfortunately not going to happen anytime soon. In the meantime, I suggest that you take a look at BeerCloak: https://g ithub.com/dteleguin/beercloak The domain-extension example is limited in a way that it doesn't support multiple realms; try adding a non-master realm, tweak invoke- authenticated.sh accordingly, and you'll get 401 everywhere. In BeerCloak, there's no such limitation, however the implementation is a bit more complex. I'd recommend that you use beercloak.resources.AbstractAdminResource as a base class for your resource. Additionally, BeerCloak uses EAR packaging, something that I would also strongly recommend - this allows you to package your provider together with dependencies, which frees you from deploying dependencies separately. Don't hesitate to write me if you have further questions. Cheers, Dmitry