I am not sure about for production use, but for development I like the idea of being able to flip a switch to turn it on/off. I also agree that option 1 is undesirable.

Le 26/01/2015 09:59, Thomas Heute a écrit : Agreed Some more context maybe. I asked the question during the hangout and here's why. The PR as-is makes it impossible: * to start a development container without KC * to run tests/integration tests without KC * to install a metrics server without KC From my perspective, that's important enough to consider making it or optional or holding the merge to let us think more about the problem.

Hi Juca, Le 27/01/2015 15:21, Juraci Paixão Kröhling a écrit : Here is a concrete advantage: not being dependent on KC to run a metrics server. More below. After your demo, my understanding was as follows. 1. In terms of APIs, the main code would depend on JAAS rather than KC (/@RolesAllowed/ and inspection of a /Subject/ for custom interceptors). So the good news is that we don't have to implement a pluggable identity/authorization tool, it's already there, it's JAAS. And KC is a possible backend. 2. With the exception of the console, the impact of making KC optional is limited to: * making the build process create two artifacts for the rest-servlet module, one WAR with KC configured in the web.xml, another WAR with "classic" security definitions * creating a JAAS login module to lookup for tenants, users, roles, in a simple properties file (or a couple of them). * finding a way for running the REST integration tests with and without KC enabled As for the console project, I understood that it is considered a facility for users of the sole metrics project, not a base for the future Hawkular suite. I'd be fine if, for now, it only supported basic/digest auth. See my answer above about integration tests impact. My last point was "The PR makes it impossible to install a metrics server without KC". I meant that if one needs to configure and run a KC server in order to run a metrics server, then many potential users will not even give it a try. Potential users here are admins and production-focused developers who are working with combos like Grafana/Graphite/collectd Even if "metrics server alone" on its own is not the team's top priority, I think it should remain *a* priority, for the reason I've just given. True, and thanks for having patiently awaited my reply ;) Thomas

Le 29/01/2015 17:08, Juraci Paixão Kröhling a écrit : That's ok, as long as we do talk about the other points ;) I know that start.sh does everything so that you get a metrics + KC instance up and running. But that is not my point. My point is that many admins will not even try the start.sh way if they realize they will *have to* install an identity management server to use metrics in the long run. When you install InfluxDB, carbon/whisper, opentsdb, you don't need to install an identity management server, period. And LDAP, RDBMS, properties file are identity management backends, KC is identity management itself. That would be nice for users who *want* KC. I can understand that we make KC a runtime requirement for the full Hawkular monty, but I can't for metrics alone. Regards, Thomas

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 01/30/2015 12:22 PM, Thomas Heute wrote: Not sure how it would work by not having security within metrics (or any other component). Each component would have a security layer around it, and the security is propagated from the outermost layer to the inner layers. Example: - - user -- UI console -- backend A -- backend B -- backend C On this situation, UI console is protected via keycloak.js, which sends a token to "backend A" representing the "user". If "backend A" needs to talk to "backend B" on behalf of the user, it sends the token with the request. But each of those components (UI console, backend A, B, C) are protected. Of course, we could also have unprotected backends and only the UI console being protected, but I think it's not really an option. Note that each component is secured by a Keycloak *adapter*. The server needs to be "somewhere", not necessarily on the same application server instance that a specific component resides (if that's what you meant above by not having it "within Metrics"). - - Juca.

On 02/04/2015 08:10 AM, Thomas Segismont wrote: That doesn't mean we compete head to head with the solutions above :) Having a multitenant solution is a differentiator and having too many options is confusing (as you can take the full hawkular, or hawkular metrics with and without secure multitenancy), we need to make choices and we need to deliver ;)

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 02/04/2015 03:23 PM, Heiko Braun wrote: No. Keycloak is a "super OAuth" solution, and that's on top of HTTP. What kind of other authentication mechanisms are you thinking about? Not that I'm aware of. All it does is to put a layer between the incoming request and the business method on the backend, like JAAS. Depends on the definition of "desirable". Right now, the common practice for projects consuming Keycloak seems to build an "appliance" distribution, which builds on top of Wildfly and delivers Keycloak pre-installed/configured + the target application (hawkular, in our case). - - Juca.

I did assume that the communication between hawkular components is not limited to HTTP. How would you secure the communication when another protocol is used? Maybe this question helps to look at security requirements within hawkular on an abstract level. What security requirements exist? What communication channels need to be secured? Maybe you'll find that keycloak only addresses part of the requirements. This will impact the question wether or not to make it a technological constraint. /HeikoB