Re: [wildfly-dev] Keycloak SSO in WildFly 9

i.e. the security infrastructure is independent from the app server installation it is securing.

Regards, Darran Lofthouse. On 05/06/14 19:01, Stan Silvert wrote: > I'm back from PTO now. Thanks to everyone for the excellent feedback. > > It sounds like the one thing we have broad agreement on is that we > should at least ship the Keycloak adapters with WildFly. That way, the > Web Console and other client apps can use Keycloak as their auth server > if they want. > > I like Darran's suggestion to go ahead and integrate the adapters as a > first task. It should keep me busy for awhile. We can keep thinking > about Keycloak auth server integration in the mean time. > > So now with a narrower focus, I still have one problem. What are the > requirements of a domain controller using Keycloak? More specifically, > is it a requirement to be able to log into Web Console when the DC is > the only thing running? > > I ask because if Web Console on DC is secured with Keycloak and it can't > reach the Keycloak auth server then you can't log in. Maybe we already > have this problem? Is it ever the case that the Web Console > authenticates against an LDAP server? If so then you have the same > problem if it can't reach the LDAP server. > > Stan > > > On 6/5/2014 4:45 AM, Darran Lofthouse wrote: >> On 04/06/14 22:05, Jason Greene wrote: >>> On Jun 4, 2014, at 2:32 PM, Bill Burke <bburke(a)redhat.com&gt; wrote: >>> >>>> On 6/4/2014 1:23 PM, Jason Greene wrote: >>>>> On Jun 3, 2014, at 1:25 PM, Darran Lofthouse <darran.lofthouse(a)jboss.com&gt; wrote: >>>>> >>>>>>> Both the auth server and admin console are served from the same WAR. It >>>>>>> should be possible to deploy this without using a WAR or servlets, but >>>>>>> that is not planned for the initial WildFly integration. Because of >>>>>>> this current limitation, the auth server and admin console will not be >>>>>>> present in a domain controller. >>>>>> This is going against the current design of AS7/WildFly exposing >>>>>> management related operations over the management interface and leaving >>>>>> the web container to be purely about a users deployments. >>>>> Sorry for my delayed reply. I hadn’t had a chance to read the full thread. >>>>> >>>>> My understanding of the original and still current goal of key cloak is to be more of an appliance, and also largely independent of WildFly. >>>>> >>>>> From that perspective, I don’t think embedding Keycloak solely to be in the same VM makes a lot of sense (more details as to why follow). It’s fine to have KeyCloak running on a WildFly instance (either as a subsystem or a deployment), but to me this seems to be a bit more of a black box to the user. >>>>> >>>>> So a typical topology, based on the factors I am aware of would look like this: >>>>> >>>>>                                                        >>>>>                                                        >>>>>                +------+     Auth       +----------+    >>>>>                |      +---------------->          |    >>>>>                |  DC  |                | Keycloak |    >>>>>           +----+      +----+           |          |    >>>>>           |    +------+    |           +----------+    >>>>>           |                |                           >>>>>       +---v--+          +--v---+                       >>>>>       |      |          |      |                       >>>>>       |  HC  |          |  HC  |                       >>>>>     +-+      +-+      +-+      +-+                     >>>>>     | +--+---+ |      | +--+---+ |                     >>>>>     |    |     |      |    |     |                     >>>>>    +v-+ +v-+ +-v+    +v-+ +v-+ +-v+                    >>>>>    |S1| |S2| |S3|    |S4| |S5| |S6|                    >>>>>    +--+ +--+ +--+    +--+ +--+ +--+                    >>>>>                                                        >>>>> >>>>> Each box represents a different JVM running potentially on separate hardware. >>>>> >>>>> So from the architecture the key element we need is for the DC (and standalone server) to come pre bundled with a client that can talk to the Keycloak blackbox (whether it be WildFly or fat jar or whatever). I assume this mostly amounts to OAUTH communication. >>>>> >>>>> Now as to why I don’t think embedding as it is makes a lot of sense, is because it wouldn’t really be a tightly integrated component, but rather two distinct systems duct taped together. We would have: >>>>> >>>>> 1. Multiple distinct management consoles >>>>> 2. Multiple distinct management APIs >>>>> 3. Multiple distinct management protocols >>>>> 4. Multiple distinct CLI/tools >>>>> >>>>> There is of course ways to paper over this and shove them together but you end up with leaky abstractions. Like lets say the CLI could issue REST operations against Keycloak as well. Thats great but that means things like the compensating transaction model don’t let you mix management changes with keycloak changes. >>>>> >>>>> Another issue is that WildFly has some pretty strict backwards compatibility contracts with regards to management that stem from EAP. Keycloak, at this stage of the process might not want to put up with us requesting similar conservative governance. It might be better for us to limit the API dependencies to best enable the project to continue to evolve. >>>>> >>>> Jason, >>>> >>>> I think we should first get Keycloak to secure Wildfly in standalone >>>> mode or with a domain controller. In both cases the Wildfly console >>>> should be securable by Keycloak. I'm betting that a lot of these issues >>>> will flesh out and become much clearer on how to solve. >>> Certainly agree there. >> +1 This is what I was trying to say in a reply to Stan earlier, getting >> to the point where we can enable keycloak based authentication for the >> http management interface in standalone mode and in domain mode sounds >> like the ideal starting point. >> >> For one in itself it is a complete deliverable task that provides a >> complete set of functionality and it completely removes any obstacle >> from those that wish to use KeyCloak instead of the standard HTTP >> mechanisms. >> >> As a second task we can then review how a default bundling with KeyCloak >> could be provided either enabled by default or enableable - but >> hopefully you can see from some of the messages here providing the >> complete solution has a lot of issues that need to be resolved. >> >>>> Irregardless of the Wildfly team vetoing the inclusion of keycloak, it >>>> is a very important use case for us to be able to be embbeded and to >>>> secure Wildfly and to manage security for Wildfly. >>>> >>>> We have already learned a lot by being embedded with Aerogear UPS as >>>> their security console and solution. For example, keycloak now has >>>> pluggable themes/skins themes/skins for its entire UI: admin console, >>>> login pages, etc. This has allowed Keycloak to be branded as an >>>> Aerogear subsystem and it looks like one product. >>> I don’t think anyone has veto’d anything. I have just highlighted the challenges. They aren’t insurmountable but they would require some effort to solve. We could for example have management operation wrappers which trigger the appropriate actions in key cloak, and this could solve the CLI problems I mentioned, and allow for the admin console to do cross system interactions. Some of the other issues I don’t have a clear idea on, but some thinking might come up with something. >> Please don't feel like anything is bein veto'd - if we were vetoing >> anything we would be coming back with lines like project elytron is well >> underway, you are going to be interfacing with existing implementations >> that we know are changing, discussing KeyCloak today is a time drain >> etc.... >> >> Personally I want to see KeyCloak in for authentication as soon as >> possible, it is going to be representative of the approaches we must be >> able to support with the wildfly-elytron work and as Stan says having a >> testable existing implementation to compare against will provide us a >> lot of benefits in this area. >> >> But for the complete solution I think we have a lot more issues to >> solve, the application server development has progressed a long way >> since we effectively just had a standalone mode server - everything we >> do we now need to consider both standalone mode and domain mode. We >> have also had a lot of input from the security response team and the >> current design constraints we operate in for our out of the box offering >> is based on a lot of discussion with them as well as other interested >> parties focussed on the developer experience. >> >> One other aspect I experience when it comes to security is if you take >> the simple problem first and solve that adding a solution for the >> complex problem becomes much harder. And then finally lets say we add a >> full standalone solution to the WildFly codebase today and leave domain >> mode to be handled second, we risk reaching a point if domain mode is >> not ready that either Jason has to release an app server with domain >> mode behaving differently to standalone mode or the release has to be >> held up. >> >> So my preference here is we identify the task that we can deliver in >> it's entirety and look at getting authentication working for both >> standalone and domain mode and then look at the default inclusion as a >> second step. This will give use something that can be documented, used, >> demoed, blogged about etc... The second stage would then be removing >> some of the manual installation tasks a user would need to perform but >> in the first stage we would have reached the major milestone of KeyCloak >> being usable for authentication when managing WildFly. >> >>>> -- >>>> Bill Burke >>>> JBoss, a division of Red Hat >>>> http://bill.burkecentral.com >>>> _______________________________________________ >>>> wildfly-dev mailing list >>>> wildfly-dev(a)lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >>> -- >>> Jason T. Greene >>> WildFly Lead / JBoss EAP Platform Architect >>> JBoss, a division of Red Hat >>> >>> >>> _______________________________________________ >>> wildfly-dev mailing list >>> wildfly-dev(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >>> >> _______________________________________________ >> wildfly-dev mailing list >> wildfly-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/wildfly-dev > _______________________________________________ > wildfly-dev mailing list > wildfly-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > _______________________________________________ wildfly-dev mailing list wildfly-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/wildfly-dev