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

In response to Jason's request for design proposals on this list, here is the proposal for Keycloak SSO in WildFly 9. Background ----------------- A major part of our console unification effort is to allow various JBoss management consoles to take advantage of Single Signon. To achieve this end, Keycloak SSO[1] will be integrated into the WildFly 9 platform. The first management consoles to use Keycloak will likely be the WildFly Web Console[2] and the JON Console. Proof of Concept ----------------------- A hacked-up proof of concept is available at https://github.com/ssilvert/wildfly/tree/kcauth. It demonstrates a WildFly standalone server using Keycloak for both authentication and authorization in the Web Console. It also shows single signon between the Web Console and the Keycloak Admin application. See https://github.com/ssilvert/wildfly/blob/kcauth/keycloak/KeycloakSetup.txt for details. One interesting finding of the POC is that the Keycloak integration required no changes to the WildFly Web Console. All the integration is done on the server side and the GWT client works perfectly as-is. 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.

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.

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.

Keycloak Database -------------------------- The Keycloak database contains all the server-side configuration data such as the data manipulated by the Keycloak Admin Console. By default, it is an H2 database that lives in the standalone/data directory. It is created when the auth server is first deployed. This database will be initialized with a single "admin" user who has all rights within the Keycloak Admin Console and within the WildFly Web Console. On first login, the admin user must change his password. By default, both consoles will be in the same master realm so that users can potentially do single signon and move freely between them. H2 is not recommended for production use. Keycloak has tools available to migrate data to another database. Keycloak Adapter ------------------------ A Keycloak adapter is a bit of software that is attached to an application deployment. This software knows how to talk to the Keycloak auth server. It handles the OAuth protocol from the client side. In the case of the WildFly Web Console, the adapter will be a pure Undertow, non-servlet adapter. The reason for using a pure Undertow adapter instead of the current Keycloak WildFly adapter is that the latter adapter relies on the Servlet API, which is forbidden on a domain controller. The proof of concept mentioned above contains the code needed for a pure Undertow adapter. This code will likely be migrated into the Keycloak project. Keycloak Adapter Configuration ------------------------------------------- A Keycloak adapter configuration is a json or DMR representation of an application's client-side Keycloak configuration. It is used by the adapter to find data such as public keys and the location of the auth server. (From the POC, see master->Applications->web-console->Installation) In the case of WildFly Web Console, we actually have two application endpoints that need to be configured and protected by Keycloak. These are the GWT-based UI and the http management endpoint that accepts DMR operations. The Keycloak configuration for these applications will live in the DMR management tree under SuperUser access. This restrictive access only applies to the Keycloak adapter configuration. Any RBAC role can be assigned to a user of the WildFly Web Console via the Keycloak Admin Console. Note that the proof of concept still uses json files for the adapter configuration. The real implementation will need to store the configuration in the DMR management tree so that it can be maintained by CLI or the WildFly Web Console. Questions for further discussion -------------------------------------------- 1. WildFly ships with pre-defined RBAC roles. [3] Should these roles be available at the realm level or only to the WildFly Web Console? Could/should other consoles make use of these roles?

2. On first login, you are required to change the admin password. What other initial setup should be required? Change realm public key? Change client secret? Others?

3. In the POC, the Keycloak Auth Server WAR is extracted into the standalone/deployments directory. Are there better options? Should it even be deployed by default?

4. By default, what Login Options should be enabled for the master realm? Currently, these options are social login, user registration, forget password, remember me, verify email, direct grant API, and require SSL. 5. Should Keycloak audit log be enabled by default? If so, what should be the expiration value? 6. What should the initial pasword policy be? (length, mixed case, special chars, etc.)

[1] http://keycloak.jboss.org/ http://docs.jboss.org/keycloak/docs/1.0-beta-1/userguide/html_single/inde... [2] https://github.com/hal/core [3] http://planet.jboss.org/post/role_based_access_control_in_wildfly_8_tech_... _______________________________________________ wildfly-dev mailing list wildfly-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/wildfly-dev