[wildfly-dev] Keycloak SSO in WildFly 9

Tue Jun 3 16:19:59 EDT 2014

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.  
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?
>
>> 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.
>
>> 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
>>
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev