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?

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>

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(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> > >

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(a)redhat.com <mailto:mposolda@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 <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> >> >> > >

What's the use-case for hawtio on EAP if not for Fuse?

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?

On 30 September 2016 at 10:35, Marek Posolda <mposolda(a)redhat.com <mailto:mposolda@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(a)redhat.com > <mailto:mposolda@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 > <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> >>> >>> >> >> > >