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

Mon Oct 3 07:30:38 EDT 2016

Ok, makes sense to have the "empty" security context tag then. Seems like a
simple and non-intrusive change.

On 30 September 2016 at 16:24, Marek Posolda <mposolda at redhat.com> wrote:

> On 30/09/16 12:58, Stian Thorgersen wrote:
>
> What's the use-case for hawtio on EAP if not for Fuse?
>
> By Hawtio on Fuse, I meant Hawtio deployed on JBoss Fuse ( karaf + jetty).
> Where Hawtio on EAP is just hawtio war deployed on EAP.
>
> AFAIK both usecases (Hawtio on JBoss Fuse and Hawtio on EAP) is what we
> want to support for "Fuse adapter" ?
>
> With Hawtio on EAP you need to change some settings in the war to add our
> login module right? So not sure why it would be an issue to add
> jboss-deployment-structure.xml at the same time?
>
> Nope, I don't change anything inside the WAR. And I want to keep it like
> that. I suppose that require people to change stuff directly inside the
> hawtio.war is not something we want to do? Otherwise I would just add
> jboss-deployment-structure.xml and I wouldn't start this thread :-)
>
> The JAAS configuration is in standalone.xml and hawtio is able to read it.
> It's just not able to find the keycloak classes. So really the only thing I
> need is a way for hawtio to find the classes. So a way for our subsystem to
> just add dependencies, but not add the deployment configuration (as I don't
> need it).
>
>
> Marek
>
> On 30 September 2016 at 10:35, Marek Posolda <mposolda at redhat.com> wrote:
>
>> On 30/09/16 08:55, Stian Thorgersen wrote:
>>
>> Wouldn't it actually be better to have the auth-server-url in
>> standalone.xml than in the JAAS login module configuration?
>>
>> Hawtio relies on JAAS and I can't see any nice way how to pass the stuff
>> from our subsystem to the JAAS login module. Also I suppose we don't want
>> to introduce any keycloak dependencies in hawtio as that would mean other
>> complications...
>>
>> Our adapter subsystem puts the stuff into the JSON string, which is saved
>> as servletContext attribute. So what can work is, that hawtio can read it
>> from the servletContext and save it to some threadLocal. Then on hawtio
>> side, there will be login module, which will read the JSON from threadLocal
>> and put it to JAAS sharedState. The Keycloak login module, which will be
>> next in the JAAS chain, can then try to see if there is stuff in
>> sharedState and if yes, then use it instead of the KeycloakDeployment
>> provided by it's JAAS config. Or another possibility that class holding
>> threadLocal will be in Keycloak codebase and hawtio will use reflection to
>> put the JSON into it (as we don't want keycloak dependencies in hawtio
>> directly).
>>
>> Both approaches looks to me complicated and introducing dependencies on
>> keycloak subsystem implementation details into hawtio codebase (reading the
>> servletContext attribute etc). Also it will be useful just with hawtio on
>> EAP, but not for Hawtio on Fuse. And Fuse seems to be much more important.
>>
>> Marek
>>
>>
>> On 30 September 2016 at 08:34, Marek Posolda <mposolda at redhat.com> wrote:
>>
>>> 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 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
>>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>
>