Without the SPI you'd have to fork the code. Adding the endpoint wouldn't be to hard though.

On 27 November 2015 at 12:19, Bystrik Horvath <bystrik.horvath@gmail.com> wrote:
forgot to reply to all ;-)
---------- Forwarded message ----------
From: Bystrik Horvath <bystrik.horvath@gmail.com>
Date: Fri, Nov 27, 2015 at 12:18 PM
Subject: Re: [keycloak-user] Limiting the admin REST API
To: stian@redhat.com


Hi Stian,

thank you for the answer. Custom endpoint would be nicer option for me as I would like to , e.g.: let the calling application use own set of of user attributes (e.g.: name of the university) and remap them onto custom attributes of user representation. Is there any way how to add own endpoint to keycloak (when the SPI is not ready for that option)?

Best regards,
Bystrik

On Fri, Nov 27, 2015 at 12:05 PM, Stian Thorgersen <sthorger@redhat.com> wrote:
Another option is that you use scope to prevent this. I imagine you will want to have a separate set of roles for your calling app in either case. In which case you make sure that you limit the scope of the clients.

On 27 November 2015 at 12:04, Stian Thorgersen <sthorger@redhat.com> wrote:
Pressed send to early. We are planning to add an SPI to allow deploying your own rest endpoints. Once we have that we can also add an option to disable admin endpoints. Although the Keycloak admin console wouldn't work anymore.

On 27 November 2015 at 12:03, Stian Thorgersen <sthorger@redhat.com> wrote:
In that case I'd say you should rather not deploy the admin endpoints at all and instead add your own custom endpoints.

On 27 November 2015 at 11:08, Bystrik Horvath <bystrik.horvath@gmail.com> wrote:
Hello everyone,

I would like to limit the functionality of the admin REST API to the calling user/application. 
The motivation is not to expose the "internals" of keycloak and put some logic between the calling app and admin REST API.
My idea was to create a simple web application deployed at keycloak server that belongs to the same realm as calling application and realm management application. 
Would you recommend that approach? Or is there anything more suitable (e.g.: implement it as a keycloak valve... etc.)?

Thank you for your opinions.

Best regards,
Bystrik



_______________________________________________
keycloak-user mailing list
keycloak-user@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-user




_______________________________________________
keycloak-user mailing list
keycloak-user@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-user



_______________________________________________
keycloak-user mailing list
keycloak-user@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-user