[wildfly-dev] Keycloak SSO in WildFly 9

Tue Jun 3 14:25:24 EDT 2014

On 03/06/14 18:46, Stan Silvert wrote:
> 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.

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.

>
> 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.  Even then how much does it make sense for each app 
server installation to have it's own SSO infrastructure?

> 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.

>
> 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?

The direction we are moving towards with the wildfly-elytron work is 
that role assignment / mapping is something that happens at the point a 
call reaches a secured resource and will be in the context of that 
secure resource.  As an example a user could call one deployment and be 
assigned one set of roles, that same user could call a different 
deployment and have a completely different set of roles - for simplicity 
we will allow a 1:1 mapping from what was loaded from the identity store 
to roles but that will not be always the case.

> 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?

This is something that would be required to happen at the command line, 
a connection from a web browser could not be trusted to perform this.

> 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?

As I say above this goes against the current architecture of separating 
management from apps.

> 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.)

Password policy is warn only for weak passwords, administrators can 
override and choose what ever they want.

>
> [1] http://keycloak.jboss.org/
> http://docs.jboss.org/keycloak/docs/1.0-beta-1/userguide/html_single/index.html
> [2] https://github.com/hal/core
> [3]
> http://planet.jboss.org/post/role_based_access_control_in_wildfly_8_tech_tip_120
>
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>