[wildfly-dev] access to mgmt api/services

[ssilvert at redhat.com]

On 2/6/2014 3:45 PM, Bill Burke wrote:
> * 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.
The subsystem can easily suck in the role definitions at deploy time. 
The question is where/how should this info can be stored.
>
>
> 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 at redhat.com> 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 at redhat.com> 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
>>