Hi Anton,
Please mind that in order to run the domainextension example under KC
>= 3.2.0, first you'll need to manually add the "admin" role to the
"admin-cli" client scope, see my previous posting here. Other answers
inline.
В Mon, 27/11/2017 в 09:30 +1100, Anton Mazkovoi пишет:
> Hi,
>> I have a small plugin that adds a simple REST service to keycloak,
> which I would like to restrict access to members of the admin role.
>> I am following the example:
>https://github.com/keycloak/keycloak/blob/3.2.1.Final/examples/provid> ers/domain-
> extension/src/main/java/org/keycloak/examples/domainextension/rest/Ex
> ampleRestResource.java
>> I am deploying the plugin by copying into the
> "standalone/deployments” directory.
>> The plugin errors out with:
> java.lang.NoClassDefFoundError:
> org/keycloak/services/managers/AppAuthManager
>> How do I declare the dependency on "keycloak-services”?
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.
>> Or is there a simpler way to restrict access to a REST service to
> admin role members?
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
>> Cheers,
> Anton
>>> _______________________________________________
> keycloak-user mailing list
>keycloak-user at lists.jboss.org>https://lists.jboss.org/mailman/listinfo/keycloak-user