access to mgmt api/services

classic Classic list List threaded Threaded
23 messages Options
12
Reply | Threaded
Open this post in threaded view
|

access to mgmt api/services

Bill Burke
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).

Also, what is the best practice for managing in-VM services that are
shared between deployments (specifically services shared between web
deployments)?
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: access to mgmt api/services

John Mazzitelli
> 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-as-dmr-client/src/main/java/org/rhq/common/jbossas/client/controller

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-client-for.html

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.
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: access to mgmt api/services

Bill Burke


On 1/27/2014 5:40 PM, John Mazzitelli 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-as-dmr-client/src/main/java/org/rhq/common/jbossas/client/controller
>
> 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-client-for.html
>
> 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.
>

Thanks for the links!

What about sharing a "service" between different applications?  i.e. a
shared service like the TxMgr.

--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: access to mgmt api/services

jtgreene
Administrator
In reply to this post by John Mazzitelli

On Jan 27, 2014, at 4:40 PM, John Mazzitelli <[hidden email]> 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-as-dmr-client/src/main/java/org/rhq/common/jbossas/client/controller
>
> 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-client-for.html
>
> 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


--
Jason T. Greene
WildFly Lead / JBoss EAP Platform Architect
JBoss, a division of Red Hat


_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: access to mgmt api/services

jtgreene
Administrator
In reply to this post by Bill Burke

On Jan 27, 2014, at 4:22 PM, Bill Burke <[hidden email]> 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).
>
> Also, what is the best practice for managing in-VM services that are
> shared between deployments (specifically services shared between web
> deployments)?

Singleton EJBs and @EJB references is the simplest. Although you could also use MSC services. Either case
means you have to deploy things together (e.g. in the same deploy operation, or part of boot) or if separate they have to be in the right order.

--
Jason T. Greene
WildFly Lead / JBoss EAP Platform Architect
JBoss, a division of Red Hat


_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: access to mgmt api/services

Bill Burke
In reply to this post by jtgreene


On 1/27/2014 6:02 PM, Jason Greene wrote:

>
> On Jan 27, 2014, at 4:40 PM, John Mazzitelli <[hidden email]> 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-as-dmr-client/src/main/java/org/rhq/common/jbossas/client/controller
>>
>> 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-client-for.html
>>
>> 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.


--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: access to mgmt api/services

Brian Stansberry
On 1/27/14, 5:15 PM, Bill Burke wrote:

>
>
> On 1/27/2014 6:02 PM, Jason Greene wrote:
>>
>> On Jan 27, 2014, at 4:40 PM, John Mazzitelli <[hidden email]> 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-as-dmr-client/src/main/java/org/rhq/common/jbossas/client/controller
>>>
>>> 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-client-for.html
>>>
>>> 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 can't be done using the HTTP management interface?

--
Brian Stansberry
Senior Principal Software Engineer
JBoss by Red Hat
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: access to mgmt api/services

Bill Burke


On 1/27/2014 7:59 PM, Brian Stansberry wrote:

> On 1/27/14, 5:15 PM, Bill Burke wrote:
>>
>>
>> On 1/27/2014 6:02 PM, Jason Greene wrote:
>>>
>>> On Jan 27, 2014, at 4:40 PM, John Mazzitelli <[hidden email]> 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-as-dmr-client/src/main/java/org/rhq/common/jbossas/client/controller
>>>>
>>>> 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-client-for.html
>>>>
>>>> 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 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.

--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: access to mgmt api/services

Bill Burke


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.




--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: access to mgmt api/services

jtgreene
Administrator

On Feb 5, 2014, at 9:23 AM, Bill Burke <[hidden email]> 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.

--
Jason T. Greene
WildFly Lead / JBoss EAP Platform Architect
JBoss, a division of Red Hat


_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: access to mgmt api/services

Bill Burke


On 2/5/2014 11:23 AM, Jason Greene wrote:

>
> On Feb 5, 2014, at 9:23 AM, Bill Burke <[hidden email]> 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.
>

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
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: access to mgmt api/services

Tomaž Cerar-2
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


On Thu, Feb 6, 2014 at 4:35 PM, Bill Burke <[hidden email]> wrote:


On 2/5/2014 11:23 AM, Jason Greene wrote:
>
> On Feb 5, 2014, at 9:23 AM, Bill Burke <[hidden email]> 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.
>

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
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev


_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: access to mgmt api/services

Bill Burke
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
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: access to mgmt api/services

jtgreene
Administrator
Is JSON not usable by non-Wildfly servers?

On Feb 6, 2014, at 9:55 AM, Bill Burke <[hidden email]> 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
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: access to mgmt api/services

Brian Stansberry
I didn't focus on this enough last week, sorry, but now I'll ask questions.

In general, can you describe more what this configuration data is?

Is this an optional behavior? Can the necessary configuration be
performed without requiring a call from the keycloak server?

The keycloak server will have to be authenticated as a valid user
authorized to administer the appserver. The account will need to have
high level permissions (Administrator or SuperUser in our RBAC scheme)
since this is presumably security-sensitive stuff being configured. Is
it going to be more user-friendly to have them set all that up versus
having them configure this stuff directly?

Is this configuration sent by the keycloak server meant to be stored in
the persistent config (e.g. standalone.xml)? In a managed domain, the
persistent subsystem configurations are controlled by the master Host
Controller, not by individual servers. So any per-server stuff can only
work with non-persistent data. Also, the HC is not going to deploy a war.

On 2/6/14, 10:01 AM, Jason Greene wrote:

> Is JSON not usable by non-Wildfly servers?
>
> On Feb 6, 2014, at 9:55 AM, Bill Burke <[hidden email]> 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
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>


--
Brian Stansberry
Senior Principal Software Engineer
JBoss by Red Hat
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: access to mgmt api/services

Bill Burke
In reply to this post by jtgreene
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 <[hidden email]> 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
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: access to mgmt api/services

jtgreene
Administrator
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 <[hidden email]> 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 <[hidden email]> 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


_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: access to mgmt api/services

jtgreene
Administrator
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

and then parse the JSON for a server-state key

Or you could just do

http://localhost:9990/management/host/master/server/server-one?operation=attribute&name=server-state

Now REST is totally subjective, and some will say "OH THATS NOT REST ENOUGH". We could support anything really, we have a model and mostly data oriented operations, but because we also have to support things that can’t be modeled as data in a straightforward and intuitive way (e.g transactions), the API is mostly RPC oriented.

Of course saying all of this might have been a complete waste of my time because I have no idea if that’s what your little sarcastic barb was even about.

On Feb 6, 2014, at 2:12 PM, Jason Greene <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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
>
>
> _______________________________________________
> wildfly-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/wildfly-dev

--
Jason T. Greene
WildFly Lead / JBoss EAP Platform Architect
JBoss, a division of Red Hat


_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: access to mgmt api/services

Bill Burke
In reply to this post by jtgreene
Honesty that insult was uncalled for.  I'm not ranting, but describing
problems I need to solve, albeit dispersed in multiple emails.  I'll
summarize more.

* I'd like to be able to have the Keycloak admin console initiate the
securing of a remotely deployed app.
* I'd like for the remotely deployed app to be able to register itself
with the Keycloak server so it can be secured.
* I need to be able to register and secure applications on Openshift
with a already deployed Keycloak server without having to edit config
files.  Aerogear UPS has this requirement.  I can't do this now without
doing port mappings on Openshift.
* 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.
* I'd like to be able to support OpenID connect RP registration
interface.  This means its client driven rather than a direct
interaction with the wildfly admin
* I'd like to be able to define a cross-platform REST interface that app
server's can implement.

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 <[hidden email]> 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 <[hidden email]> 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
>

--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: access to mgmt api/services

Bill Burke
In reply to this post by jtgreene
I replied and summarized more in a separate email as the points.  I'm
not complaining just trying to figure out how to implement things.  I
agree that REST can be subjective.  But the JSOn format mentioned is
tailored and specific to Wildfly.

On 2/6/2014 3:37 PM, Jason Greene wrote:
> 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
>

I did not know about this, AFAIK, its not documented.  Only thing I saw
was the RPC JSON HTTP API thingy.  This helps in a lot of cases, but not
others.  Don't have time now, I"ll try to expand more later.

--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
12