[wildfly-dev] access to mgmt api/services

[Bill Burke]

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

-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com