[wildfly-dev] Creating a Keycloak Feature Pack

Stan Silvert ssilvert at redhat.com
Wed Sep 10 14:47:23 EDT 2014

Perhaps it's a little early to start implementing a Keycloak FP, but I'm 
starting to look at it and identify potential issues.  So I thought I 
should list the issues here and find out which ones are already 
addressed and which need some time to work out.

*Task:*  Implement a feature pack that adds the Keycloak Auth Server to 
either/both of the _WildFly Web build_ and the _WildFly Full build_.

Note that this is completely separate from the effort to use Keycloak to 
secure the web console.  That only involves Keycloak adapter integration 
destined to ride on top of Elytron.

Here, we are talking about using a feature pack to add and configure the 
Keycloak Auth Server.

*Issue #1:  Module duplication.*  Keycloak needs to install the 
bouncycastle module.  This module already exists in the full build but 
not the web build.   So you have the same module specified for the 
Keycloak FP and the Full WildFly FP.

I assume this is already handled?  Will the FP mechanism have a problem 
with duplication of modules when I try to add a module to full that 
already exists?

*Issue #2: Adding a subsystem:* It looks like the current mechanism for 
creating configuration files is inappropriate for the Keycloak FP.  The 
way this is done right now is that a config file is generated via the 
combination of a template file and a list of subsystem snippets.  So you 
would have, for example:

template-keycloak.xml + subsystems-keycloak.xml = standalone-keycloak.xml

But that's not what we really want.  We don't want a separate 
standalone-keycloak.xml.  We really just want to add the keycloak 
subssytem to every generated config file, whatever they may be.

*Issue #3: Adding a deployment:*  The Keycloak auth server is deployed 
as a WAR.  We can use the copy-artifacts mechanism to simply copy the 
WAR into the deployments directory.  But that doesn't work for a domain 
where you want to have the WAR pre-loaded into the content repository.  
Furthermore, it's probably not the best way to integrate this for 
standalone either.

What would be a better option?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20140910/3204da1f/attachment-0001.html 

More information about the wildfly-dev mailing list