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

On 03/06/14 21:19, Stan Silvert wrote: > On 6/3/2014 2:25 PM, Darran Lofthouse wrote: >> On 03/06/14 18:46, Stan Silvert wrote: >>> Relation to the Elytron and other WildFly 9 changes >>> ------------------------------------------------------------------------ >>> Keycloak is expected to use Elytron at a low level. Nothing at the >>> Keycloak integration level should be affected by the Elytron project. >>> >>> However, there are many other expected changes to security that may >>> effect how Keycloak is integrated. It is likely that the initial >>> integration of Keycloak will happen before these aforementioned >>> changes. This will be an advantage as the unit tests for Keycloak >>> integration can help to validate these changes. >> One important change we will need to get in first is the splitting of >> the contexts that server the management requests, the existing >> /management context needs to remain supporting the existing >> authentication mechanisms with cross origin restrictions left on. > This will be fine. There is presently no reliance on CORS. >>> Default Authentication Mechanism >>> ------------------------------------------------ >>> Keycloak is a very new technology. Given that security is so vital, we >>> need time for Keycloak to mature. When Keycloak is first integrated, it >>> will not be the default authentication/authorization mechanism for the >>> WildFly Web Console. However, selecting Keycloak for authentication >>> should be as simple as executing one or two CLI commands. >>> >>> We can switch to Keycloak as the default whenever we all believe that >>> both Keycloak itself and its integration into WildFly are ready for >>> prime time. Hopefully, that will just be a matter of months after first >>> integration. >> We also need to have the SSL out of the box or as soon as possible after >> problem solved. > +1 >> Even then how much does it make sense for each app >> server installation to have it's own SSO infrastructure? > It's important to at least have it available as an option to turn on. That part I am fine with, out biggest concern is the WildFly distribution needs to be fully functional out of the box which means for KeyCloak to be used by default we need everything in that single instance. On the other hand, here are the steps you need to go through including how to set up your SSO infrastructure and cross reference it from the WildFly configuration is fine. Even installing it as a war on a WildFly installation in this context is fine as by then you have reached a point where the purpose of that installation is to host KeyCloak. If I am reading your results from the POC correctly this may be the best way to go anyway to get a standalone and domain mode solution available simultaneously - packaging and distribution options for a complete solution could be a second step. One point while I think of it - we will need the native management interface to be secured by the same identity store and make sure the existing http mechanisms can use the same store, if that has not already been considered that may be a higher priority. > In production, the SSO infrastructure wouldn't be live on every instance. > > Also, Keycloak is much more than just SSO infrastructure. Other > features like user management, password management, auditing, skinning, > and the nice UI make it an excellent choice for applications that don't > require SSO. Who wants to keep coding all that stuff by hand? Auditing I am deliberately ignoring other than to say that is going to be a big topic in itself ;-) We already have two auditing solutions in WildFly one purely for management, the other for apps - the app auditing is tied very closely to the JAAS integration so we know something will happen in that area. From the perspective of wildfly-elytron we haven't reviewed auditing yet as it should not be driving the security solution.

>>> Initial Integration >>> ------------------------ >>> The initial integration for most of Keycloak will only be available on >>> standalone. However, on a domain controller, the WildFly Web Console >>> will still be able to use Keycloak for authentication and >>> authorization. In this case, the domain controller must be able to >>> reach a Keycloak Authentication Server somewhere on the network. >>> >>> >>> Keycloak Authentication Server and Admin Console >>> ----------------------------------------------------------------------- >>> The Keycloak Authentication Server is responsible for authenticating and >>> authorizing users. The Keycloak Admin Console is an AngularJS UI that >>> administrators use to manage users, roles, sessions, passwords, assigned >>> applications, etc. >>> >>> 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. > The auth server and admin console don't necessarily need to be deployed > as a WAR. It's an AngularJS app, so we could make it work exactly the > same way the web console does. There is also a middle ground where > don't expose the fact that it's a WAR. I think JON does something like > that? > > This is a big discussion we will need to have. +1 As I say above it may be better to first reach the point where a WildFly instance can be configured to use an existing KeyCloak installation in standalone and domain mode (and with the native interface and standard http mechanisms) and then address the how to bring the rest of KeyCloak in as a second step. Finding a way to bring it all in would be a pre-requisite for an out of the box solution, we also have other items to bring up again soon such as continuing with out of the box authentication not dependent on SSL (although this has it's own issues if content in the management model is sensitive). But as I understand some of the demand for this the first major problem is there is no way for users to even enable this form of SSO so getting the first step enabled would be a major step forward. One point to clarify (not saying anyone is saying this but just to be clear) - I don't see us reaching a point where we say KeyCloak is exclusively the only authentication approach we will support for management, we have legacy client support requirements and end users will also have their own set of preferred solution. _______________________________________________ wildfly-dev mailing list wildfly-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/wildfly-dev