[keycloak-dev] Designing Auth Server startup from subsystem

I have a prototype working and I think I've got the lay of the land. Now I need help to make design decisions. (BTW, every time I say WildFly I mean WildFly or EAP) *Background* Deployment to the /deployments directory is generally discouraged, especially in production environments. In a domain configuration, it is impossible because there is no deployment scanner and no /deployments directory. Today, if you want to use the Keycloak Auth Server in a domain, you must upload the WAR to the content repository and assign it to one or more server groups. This not only adds extra installation steps, it complicates management of the auth server. The auth server could be assigned to WildFly instances where Keycloak modules are not installed. Furthermore, WildFly administrators with highly restricted roles in the web console and CLI would have too much control over the auth server deployment. IMO, only Administrator or higher should be able to control the auth server deployment. [1] *Subsystem-based Deployment* The Keycloak Auth Server can instead be deployed as part of the Keycloak Subsystem[2]. The plan is to make subsystem deployment an option on both standalone and domain installations. This makes the Auth Server into more of a service instead of an end-user application. *Questions and Design Decisions* The Auth Server WAR will live in its own module. Is there any reason for it to be in exploded form? The Keycloak Subsystem will get a new resource called "auth-server". Right now I only plan to have one attribute called "enabled". By default, this will be false in a domain environment. You don't want an auth server to boot everywhere you install the keycloak subsystem. Do we want this to be true for standalone? In other words, should the auth server automatically boot if the keycloak subsystem is installed on standalone? Are there any other attributes to add? The Keycloak subsystem can do anything it wants to the auth server at deployment time. It can change context params, add modules, boot in some kind of admin-only mode, or anything else. Configuration settings on the WAR could be made from standalone.xml, domain.xml, CLI, etc. Anything you would like the subsystem to do? Do I need to allow for multiple auth server deployments in the same WildFly instance? This is quite easy to do. For the second instance, it would override the module name of the auth server WAR. What are the plans and considerations for clustered auth server? Anything I should be aware of at this point? [1] http://planet.jboss.org/post/role_based_access_control_in_wildfly_8_tech_... [2] See "A Mixed Apporach" https://developer.jboss.org/wiki/ExtendingAS7