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?