[keycloak-dev] Allow adapter subsystem to just inject dependencies
Stian Thorgersen
sthorger at redhat.com
Fri Sep 30 02:55:59 EDT 2016
Wouldn't it actually be better to have the auth-server-url in
standalone.xml than in the JAAS login module configuration?
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
>>>
>>
>>
>>
>
>
More information about the keycloak-dev
mailing list