Some good news:
- Keycloak integration is finally working with hawtio on JBoss Fuse,
Apache karaf or standalone Jetty and Tomcat
- Login, logout from hawtio and single-sign-out from different app are
- Added some instructions how to have things working if anyone wants to
take a look:
- I am working with hawtio master and doing changes in my local hawtio
fork. I've squashed all my current changes in last commit of branch
https://github.com/mposolda/hawtio/blob/hawtio-keycloak for easier review
- I suppose that keycloak integration is not mandatory and enabled just
on demand. So I still kept hawtio default login mechanism and keycloak
authentication is enabled by config switch.
- As I already mentioned, hawtio is not using servlet authentication.
They have JAAS used to authenticate. So the approach I have for
server-side authentication is based on JAAS BearerTokenLoginModule,
which is able to authenticate user based on KC accessToken, which is
passed to it as password via CallbackHandler.
- The second approach might be to reuse jetty adapter, which would mean
that hawtio.war should be changed to have servlet security enabled and
then there is HttpFilter, which will establish JAAS authenticated
Subject to perform jolokia calls. Which approach is better also depends
on whether keycloak integration will be 1st class citizen in JBoss Fuse
and will be installed by default. If Jetty adapter is going to be
installed by default in fuse, then it's maybe easier to take adapter
approach for hawtio too. But I still don't know how deep is keycloak
integration supposed to be and if it's mandatory for fuse or not...
Things I still need to look at:
- Jolokia and JMX security
- More testing and bugfixing (just figured out during testing before
writing this mail that gogo is not working from hawtio console. There
are likely more minor things, which should be addressed...)
- Look at installing keycloak jetty adapter to fuse
The demo WARS have this in jboss-deployment-structure.xml:
<!-- the Demo code uses classes in these modules. These are
optional to import if you are not using
Apache Http Client or the HttpClientBuilder that comes
with the adapter core -->
I can optionally load this module using the subsystem. That is, if the
module is installed on EAP/WildFly, add it to the deployment.
Should I do this?
I prototyped some adapter refactoring and it didn't get much simpler so
I just ditched the work. I'll add some more testing then move on to
JBoss, a division of Red Hat
I'd like to do a release very soon so we can get the Jetty and Tomcat
adapters into the field. Since we now have 8 different Java adapters
for 3 different servlet containers, I'm going to work on refactoring the
adapters this week to see if I can simplify the design and push more
common code into a common module.
After that I'd like to take a break from integration work. Maybe work
on IP Filtering and/or claim support.
JBoss, a division of Red Hat
I was doing some tests and I got the following behavior:
1) User logged in in SPA
2) User is deleted via admin console
3) User try to logout from SPA
4) Nothing happens, I'm still logged in.
Is not better to return a specific error message to the SP during a logout telling whether the logout was successful or not ? And maybe depending on the status of the response automatically logout the user from the SP as well ?
Few questions about hawtio integration:
- What hawtio version are we targetting? For now I am working with
hawtio master (1.5-SNAPSHOT) but checked that
jboss-fuse-6.1.0.redhat-379 is based on hawtio-1.2-redhat-379 .
- Will be hawtio default authentication mechanism still kept and
Keycloak integration available just on demand? Or is it hawtio going to
be removed and replaced by Keycloak entirely? For now I suppose that
it's former case, so default + Keycloak authentication should be both
available and Keycloak is going to be enabled by some configuration switch.
- Are we targetting future versions of hawtio and JBoss fuse or also
current versions? In other words, is it the point also to have keycloak
authentication working in existing jboss-fuse-6.1.0.redhat-379? It may
be tricky to add to current versions and it may require people to
add/edit some JS files for have integration available. But it's doable
let me try this again to the keycloack list
> On Nov 6, 2014, at 3:54 PM, Corinne Krych <corinnekrych(a)gmail.com> wrote:
> On 06 Nov 2014, at 21:50, Lucas Holmquist <lholmqui(a)redhat.com> wrote:
>> so i was playing with the Shoot demo for iOS and connecting it to KC, a little research for a possible node.js adapter.
>> Anyway, i got everything working, i was able to perform the OAuth2 login, redirect back and upload a photo.
>> Then i went into the KC admin console thing, and disabled both the OAuth Client(shoot-third-party ) and the shoot-services, but when i then tried to upload, i was still successful.
> looks like there is an issue on revoking token on KC
> worth bringing the topic on keycloak IRC/mailing list
>> i guess i was under the impression that once one or both of those things are disabled, the upload shouldn’t work.
>> as i’m writing i saw this PR come through, https://github.com/aerogear/aerogear-ios-cookbook/pull/45, not sure if this will solve this issue though
> Nope this one is about refreshing so it will not solve the pb
>> aerogear-dev mailing list
> aerogear-dev mailing list