access to mgmt api/services

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

Re: access to mgmt api/services

Stan Silvert
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 <[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

Jason T. Greene
In reply to this post by Bill Burke
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?

> On Feb 6, 2014, at 2:51 PM, Bill Burke <[hidden email]> wrote:
>
> 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
Reply | Threaded
Open this post in threaded view
|

Re: access to mgmt api/services

Bill Burke


On 2/6/2014 9:27 PM, Jason Greene wrote:
> Ok thanks I think I understand better about what you are looking for. If you have time could you look at Brian's questions?
>

Stan and I are talking to Brian offline.  I think there's some
interesting problems we're trying to solve here.  Especially the
Openshift cartridge bootstrapping problem.

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

Not sure what you mean.  Keycloak would be the proxy to a OpenID IDP?
Like we currently already do for social login?


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