On 29/09/16 10:09, Stian Thorgersen wrote:
Oki, so sounds like what you proposed is the way to go. I'm not
to
keen on option 2 or 3 as they seem a bit artificial. Why do they not
need auth-server-url though?
Ok, I've created
https://issues.jboss.org/browse/KEYCLOAK-3634 . The
auth-server-url is needed, but this is provided by the JAAS login module
configuration. Hawtio itself just relies on the JAAS. It doesn't have
servlet security or any security-constraints in web.xml, so doesn't rely
on classic servlet adapter.
Marek
On 29 September 2016 at 08:18, Marek Posolda <mposolda(a)redhat.com
<mailto:mposolda@redhat.com>> wrote:
On 28/09/16 10:58, Stian Thorgersen wrote:
> Not sure even using "<secure-deployment...>" makes sense at all
> in this case. If there's keycloak.json the subsystem still
> injects the dependencies, but doesn't do any configuration. Why
> can't it just rely on that?
Without "secure-deployment", you also need the KEYCLOAK in
login-config in web.xml in addition to keycloak.json.
Anyway, regarding usability, I suspect it's not an option to
require people to crack inside hawtio.war and change the things in
the WAR directly? Otherwise they can just add
jboss-deployment-structure.xml into the hawtio.war and I don't
need to care about subsystem at all.
Marek
>
> On 26 September 2016 at 16:39, Marek Posolda <mposolda(a)redhat.com
> <mailto:mposolda@redhat.com>> wrote:
>
> I've did some testing with hawtio on EAP 7. It works fine,
> however there
> is one thing in our subsystem, which may improve integration
> a bit.
>
> Hawtio doesn't use servlet security ( security-constraints in
> web.xml )
> but they rely on JAAS, which is needed for JMX calls to be
> performed on
> behalf of JAAS Subject. Hawtio WAR needs to have access to
> keycloak-adapter classes (as it needs login modules for
> JAAS), however
> it doesn't need subsystem to configure adapter. This is all
> handled by
> JAAS login module.
>
> In other words, it will be nice if subsystem can just inject
> dependencies ( KeycloakDependencyProcessor ), but ignore adding
> subsystem configuration (
> KeycloakAdapterConfigDeploymentProcessor ).
>
> The workaround I used was to add secure-deployment section to
> standalone.xml with some dummy values, which are mandatory for
> subsystem. It works, but it's really not too pretty IMO.
> Something like:
>
> <secure-deployment name="hawtio.war">
> <resource>does-not-matter</resource>
> <auth-server-url>does-not-matter</auth-server-url>
> </secure-deployment>
>
> What will be nice is to have some of those possibilities:
>
> 1) Have subsystem to use some default values like "undefined"
> instead of
> null . This is more a workaround as subsystem will still
> process the
> KeycloakAdapterConfigDeploymentProcessor. However it's less
> work and it
> will improve usability, so this will work just fine:
>
> <secure-deployment name="hawtio.war" />
>
>
> 2) Tell the subsystem to ignore
> KeycloakAdapterConfigDeploymentProcessor. Looks like more
> work, but
> seems to be more proper solution than (1). I can think of:
>
> 2.a) some flag like:
>
> <secure-deployment name="hawtio.war"
> ignore-deployment-config="true" />
>
> 2.b) Use different element like "deployment" instead of
> "secure-deployment" . The "deployment" will inject
> dependencies, but
> won't handle adapter configuration. So something like this
> will work:
>
> <deployment name="hawtio.war" />
>
>
> WDYT?
> Marek
>
>
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev(a)lists.jboss.org
> <mailto:keycloak-dev@lists.jboss.org>
>
https://lists.jboss.org/mailman/listinfo/keycloak-dev
> <
https://lists.jboss.org/mailman/listinfo/keycloak-dev>
>
>