3:26 p.m.
On 01/09/16 01:23, Brian Stansberry wrote:
> On Aug 31, 2016, at 6:12 PM, Jason T. Greene <jason.greene(a)redhat.com> wrote:
>
>
>
>> On Aug 31, 2016, at 4:51 PM, Brian Stansberry <brian.stansberry(a)redhat.com>
wrote:
>>
>>
>>> For example the GWT app could be mostly client side, with no GWT-RPC
>>
>> That part is still involves a deployment though, right? Even if it’s just like
HAL and just static files, making it downloadable means either a deployment or some custom
integration into the undertow subsystem. The alternative is to make it a special context
on the management http interace like we do for the HAL console. Or one way or the other
make it part of HAL. But my impression of this app is despite the bit of integration into
HAL, it’s not really a “management” app and is meant to be usable outside of HAL. A
"dev-ops" admin may use it, hence the integration with HAL, or a “dev" may
use it, but a classic “ops” admin is not going to use it and we don’t want to force the
“dev” user to be given admin permissions in order to use it.
>>
>> If the downloadable part is a deployment but also an patchable official part of
the software we for sure don’t want it deployed via the deployments/ folder.
>
> By deployment I was referring to going through the deployment process, and registered
as a deployment node, in order to start. With client side JS it's just static files
and trivial to install wherever is desired. For example, the subsystem could register a
handler as part of the server, or the web services subsystem could register a handler as
part of a *user* deployment (a special opt in sub URL) or it could be a direct HAL plugin,
or yet another app on 9990 and thus usable on a DC.
>
Yes. I went to dinner before getting a chance to reply to myself saying I didn’t want to
distract from your main point about how to integrate, since I realized that if all the
“deployment” part was was serving static files, having the subsystem integrate a simple
handler into the webserver is a perfectly good approach.
> As to roles, sure I doubt a standard admin would do much with this. I could maybe see
an operator perhaps verifying service functionality, or perhaps troubleshooting. It
definitely seems more of a development use case. In a pure client side solution you
aren't really introducing the need for a permission per se because it runs straight
from the client browser, with no management API interaction other than discovering the
port.
>
True. We’d need to restructure how the “9090” interface is set up though. Now it’s the
“http management” interface with a single security realm. If it became something more
general purpose with different security policies for different contexts that would require
a different config style
I wouldn't worry too much about security realms as they are deprecated
and TBH will make everyone's life easier if no new resource make use of
them.
The replacement security architecture is however better suited to having
different authentication policies for different entry points to the
server and even if those entry points end up calling a common back end
we have formal support for security domain to security domain identity
propagation / transformation.
Add to that using the same security architecture for applications and
management makes it much easier to mix and match as well.
> On the other hand i suspect this relies on CXF to generate the client side messages,
so perhaps it would be a complex transition.
>
> -Jason
>