Is there an example somewhere of getting access to the mgmt api from a deployed servlet app? I'd like to be able to manage subsystem configuration and store it (within standalone.xml or whatever).

> Is there an example somewhere of getting access to the mgmt api from a > deployed servlet app? I'd like to be able to manage subsystem > configuration and store it (within standalone.xml or whatever). You can take a look at RHQ's DMR client library. It was written to be a generic DMR client to access the mgmt API. https://git.fedorahosted.org/cgit/rhq/rhq.git/tree/modules/common/jboss-a... Obtain a ModelControllerClient "somehow" (see MCCHelper, for example) and pass it to the constructor for the different types of clients (DatasourceJBossASClient, CoreJBossASClient, SecurityDomainJBossASClient, etc, etc) Then there is my blog from 2012 that talks about getting a co-located ModelControllerClient that may be of help: http://management-platform.blogspot.com/2012/07/co-located-management-cli... Anyway, the code in those places can serve as examples that you are asking for. We do use these from within servlets and EJBs running in EAP 6.

On 1/27/2014 6:02 PM, Jason Greene wrote: > > On Jan 27, 2014, at 4:40 PM, John Mazzitelli <mazz(a)redhat.com&gt; wrote: > >>> Is there an example somewhere of getting access to the mgmt api from a >>> deployed servlet app? I'd like to be able to manage subsystem >>> configuration and store it (within standalone.xml or whatever). >> >> You can take a look at RHQ's DMR client library. It was written to be a generic DMR client to access the mgmt API. >> >> https://git.fedorahosted.org/cgit/rhq/rhq.git/tree/modules/common/jboss-a... >> >> Obtain a ModelControllerClient "somehow" (see MCCHelper, for example) and pass it to the constructor for the different types of clients (DatasourceJBossASClient, CoreJBossASClient, SecurityDomainJBossASClient, etc, etc) >> >> Then there is my blog from 2012 that talks about getting a co-located ModelControllerClient that may be of help: >> >> http://management-platform.blogspot.com/2012/07/co-located-management-cli... >> >> Anyway, the code in those places can serve as examples that you are asking for. We do use these from within servlets and EJBs running in EAP 6. > > There are some caveats to this though: > > 1. You can’t make a management call during the call patch of deployment (servlet initializers etc), since deployment itself is part of a management call, and thus you will deadlock trying to start a parallel modification (until the op triggering the deployment times out). A runtime thread is fine though. > > 2. You won’t get responses on things which impact your deployment or the servlet container (e.g. redeploying yourself or downing the container) > > 3. Role based access control is defeated, all management ops will appear to come from the container itself. > > 4. Due to 3 if someone is running WildFly under a security manager you will need permissions > This is for bootstrap purposes for getting a Wildfly instance to join a Keycloak federation. I want the Keycloak server to be able to send realm configuration information to a Wildfly instance (over HTTP(S)) that is joining the federation and have that instance store this information within a subsystem. So, it is a one off service that happens after boot and may even be disabled afterwards.

>> This is for bootstrap purposes for getting a Wildfly instance to join a >> Keycloak federation. I want the Keycloak server to be able to send >> realm configuration information to a Wildfly instance (over HTTP(S)) >> that is joining the federation and have that instance store this >> information within a subsystem. So, it is a one off service that >> happens after boot and may even be disabled afterwards. >> >> > > This can't be done using the HTTP management interface? > After thinking a bit, I guess it could just use the HTTP mgmt intf. Thanks for your patience helping me work this out.

On Feb 5, 2014, at 9:23 AM, Bill Burke <bburke(a)redhat.com&gt; wrote: > > > On 1/27/2014 9:48 PM, Bill Burke wrote: >>>> This is for bootstrap purposes for getting a Wildfly instance to join a >>>> Keycloak federation. I want the Keycloak server to be able to send >>>> realm configuration information to a Wildfly instance (over HTTP(S)) >>>> that is joining the federation and have that instance store this >>>> information within a subsystem. So, it is a one off service that >>>> happens after boot and may even be disabled afterwards. >>>> >>>> >>> >>> This can't be done using the HTTP management interface? >>> >> >> After thinking a bit, I guess it could just use the HTTP mgmt intf. >> Thanks for your patience helping me work this out. >> > > Ok, found a reason why just using the HTTP mgmt interface isn't good enough: > > Openshift disables admin port :( You can set up port forwarding to be > able to access it, but, still kinda sucks for usability, which is what > I'm trying to optimize. We have been planning to provide an OTB single port config for open shift, but it fell through the cracks. IIRC all of the hooks are there for it. I’ll put that on my TODO after we cut 8 Final, perhaps bundle it in 8.0.1.

Maybe it is really time to write keycloak subsystem, that way you will be able to expose also keycloak config via rest (and other mechanism) -- tomaz

Yet another reason is that it would be cool if there were a unified, common REST API that the Keycloak admin console could use to manage and talk to server instances that want to join or be managed by a Keycloak realm. Without this common REST API, we would have to write a Keycloak server adapter (and UI screens) to handle them, which would mean that the Keycloak server would probably have to be shut down too to install any new adapter. The OP asked how to get access, locally, to mgmt api/services. Brian's response was, "just use the HTTP interface". I now have 2 reasons why "just use the HTTP interface" may not be feasible.

Is JSON not usable by non-Wildfly servers? On Feb 6, 2014, at 9:55 AM, Bill Burke <bburke(a)redhat.com&gt; wrote: > We already have a keycloak subsystem. Again, the issue is, the Wildfly mgmt REST interface is Wildfly specific, with Wildfly peculiarities, using wildfly specific envelope formats. Not very useful for non-wildfly servers. :) > > This isn't just Keycloak though. OpenID Connect has a registration REST API which is client driven and not IDP driven. > > On 2/6/2014 10:38 AM, Tomaž Cerar wrote: >> Maybe it is really time to write keycloak subsystem, that way you will >> be able to expose also keycloak config via rest (and other mechanism) >> >> -- >> tomaz >> > >> Yet another reason is that it would be cool if there were a unified, >> common REST API that the Keycloak admin console could use to manage and >> talk to server instances that want to join or be managed by a Keycloak >> realm. Without this common REST API, we would have to write a Keycloak >> server adapter (and UI screens) to handle them, which would mean that >> the Keycloak server would probably have to be shut down too to install >> any new adapter. >> >> The OP asked how to get access, locally, to mgmt api/services. Brian's >> response was, "just use the HTTP interface". I now have 2 reasons why >> "just use the HTTP interface" may not be feasible. >> > > -- > Bill Burke > JBoss, a division of Red Hat > http://bill.burkecentral.com -- Jason T. Greene WildFly Lead / JBoss EAP Platform Architect JBoss, a division of Red Hat _______________________________________________ wildfly-dev mailing list wildfly-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/wildfly-dev

Lol. Sure. You want non Wildfly servers to standardize on: {"operation":"read-attribute","address":[{"host":"master"},{"server":"server-01"}],"name":"server-state","json.pretty":1}' Nope... Still doesn't solve client initiated registration. On 2/6/2014 11:01 AM, Jason Greene wrote: > Is JSON not usable by non-Wildfly servers? > > On Feb 6, 2014, at 9:55 AM, Bill Burke <bburke(a)redhat.com&gt; wrote: > >> We already have a keycloak subsystem. Again, the issue is, the Wildfly mgmt REST interface is Wildfly specific, with Wildfly peculiarities, using wildfly specific envelope formats. Not very useful for non-wildfly servers. :) >> >> This isn't just Keycloak though. OpenID Connect has a registration REST API which is client driven and not IDP driven. >> >> On 2/6/2014 10:38 AM, Tomaž Cerar wrote: >>> Maybe it is really time to write keycloak subsystem, that way you will >>> be able to expose also keycloak config via rest (and other mechanism) >>> >>> -- >>> tomaz >>> >> >>> Yet another reason is that it would be cool if there were a unified, >>> common REST API that the Keycloak admin console could use to manage and >>> talk to server instances that want to join or be managed by a Keycloak >>> realm. Without this common REST API, we would have to write a Keycloak >>> server adapter (and UI screens) to handle them, which would mean that >>> the Keycloak server would probably have to be shut down too to install >>> any new adapter. >>> >>> The OP asked how to get access, locally, to mgmt api/services. Brian's >>> response was, "just use the HTTP interface". I now have 2 reasons why >>> "just use the HTTP interface" may not be feasible. >>> >> >> -- >> Bill Burke >> JBoss, a division of Red Hat >> http://bill.burkecentral.com > > -- > Jason T. Greene > WildFly Lead / JBoss EAP Platform Architect > JBoss, a division of Red Hat > -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com

BTW the reason I am complaining is because most of the time I have to GUESS what you are actually complaining about. Like is it the fact that you want reads to be more “REST” like? Well you can do normal GETs if you want: http://localhost:9990/management/host/master/server/server-one

Ok thanks I think I understand better about what you are looking for. If you have time could you look at Brian's questions?

One question I would add to his is related to the point you listed about OpenID, do you mean add in support for OpenID proxying from the app server to the keycloak server? Or am I way off?

* I'd like to be able to register and secure a deployed app, as well as suck in all its role definitions so things don't have to be manually configured through our admin console. This should be possible in 1 click.

Stan already wrote a subsystem for us. The subsystem stores config information about the realm and deployment to realm mappings so you don't have to crack open an existing WAR to secure it with Keycloak. What I'm trying to figure out are ways to optimize the user experience as described above. Just using the Wildfly HTTP REST interface can't meet my current requirements. On 2/6/2014 3:12 PM, Jason Greene wrote: > No but I would like to see a realistic proposal from you instead of your typical non-informed rants. > > On Feb 6, 2014, at 12:48 PM, Bill Burke <bburke(a)redhat.com&gt; wrote: > >> Lol. Sure. You want non Wildfly servers to standardize on: >> >> {"operation":"read-attribute","address":[{"host":"master"},{"server":"server-01"}],"name":"server-state","json.pretty":1}' >> >> Nope... Still doesn't solve client initiated registration. >> >> On 2/6/2014 11:01 AM, Jason Greene wrote: >>> Is JSON not usable by non-Wildfly servers? >>> >>> On Feb 6, 2014, at 9:55 AM, Bill Burke <bburke(a)redhat.com&gt; wrote: >>> >>>> We already have a keycloak subsystem. Again, the issue is, the Wildfly mgmt REST interface is Wildfly specific, with Wildfly peculiarities, using wildfly specific envelope formats. Not very useful for non-wildfly servers. :) >>>> >>>> This isn't just Keycloak though. OpenID Connect has a registration REST API which is client driven and not IDP driven. >>>> >>>> On 2/6/2014 10:38 AM, Tomaž Cerar wrote: >>>>> Maybe it is really time to write keycloak subsystem, that way you will >>>>> be able to expose also keycloak config via rest (and other mechanism) >>>>> >>>>> -- >>>>> tomaz >>>>> >>>>> Yet another reason is that it would be cool if there were a unified, >>>>> common REST API that the Keycloak admin console could use to manage and >>>>> talk to server instances that want to join or be managed by a Keycloak >>>>> realm. Without this common REST API, we would have to write a Keycloak >>>>> server adapter (and UI screens) to handle them, which would mean that >>>>> the Keycloak server would probably have to be shut down too to install >>>>> any new adapter. >>>>> >>>>> The OP asked how to get access, locally, to mgmt api/services. Brian's >>>>> response was, "just use the HTTP interface". I now have 2 reasons why >>>>> "just use the HTTP interface" may not be feasible. >>>>> >>>> -- >>>> Bill Burke >>>> JBoss, a division of Red Hat >>>> http://bill.burkecentral.com >>> -- >>> Jason T. Greene >>> WildFly Lead / JBoss EAP Platform Architect >>> JBoss, a division of Red Hat >>> >> -- >> Bill Burke >> JBoss, a division of Red Hat >> http://bill.burkecentral.com > -- > Jason T. Greene > WildFly Lead / JBoss EAP Platform Architect > JBoss, a division of Red Hat >