[keycloak-dev] Allow adapter subsystem to just inject dependencies

[Stian Thorgersen]

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?

On 29 September 2016 at 08:18, Marek Posolda <mposolda at 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 at 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 at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160929/9b560123/attachment-0001.html