[wildfly-dev] Keycloak SSO in WildFly 9
Stan Silvert
ssilvert at redhat.com
Tue Jun 3 13:46:30 EDT 2014
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/index.html
[2] https://github.com/hal/core
[3]
http://planet.jboss.org/post/role_based_access_control_in_wildfly_8_tech_tip_120
More information about the wildfly-dev
mailing list