[keycloak-dev] Notes on KEYCLOAK-795: Move Auth Server into KC subsystem

[Stan Silvert]

On 10/31/2014 5:33 PM, Marek Posolda wrote:
> Hi Stan,
>
> did you already tried to test with more auth-servers per Wildfly 
> instance? I am seeing some potential issue in the fact that some stuff 
> is static (at least KeycloakApplication.loadConfig() is static method 
> and configProvider field in org.keycloak.Config is static too). It 
> looks that this might need some refactoring (unless we want to share 
> the same config among all auth-servers, which seems as bad solution to me)
>
> I did not try myself yet to test with more auth-servers, just raising 
> potential issue;-)
Yes, I tested it.  Each server is its own deployment and thus runs under 
its own classloader.
>
> Marek
>
> On 29.10.2014 14:28, Stan Silvert wrote:
>> I've sent a PR for this:
>> https://github.com/keycloak/keycloak/pull/811
>>
>> It's a pretty big change in the way the Auth Server is started when 
>> the KeyCloak subsystem is used.  The WAR is no longer dropped into 
>> the standalone/deployments directory.   This is especially helpful 
>> for domain deployments, but it makes standalone cleaner as well.  It 
>> will also be important for Feature Pack installation.
>>
>> The main difference you will see right away with this PR is that the 
>> appliance dist now uses the subsystem to launch the Auth Server.
>>
>> Here are some notes about how everything turned out.  Next, I'll 
>> update the documentation if there is no major rework that needs to be 
>> done after the PR is reviewed.
>>
>>   * The WAR for the auth server now lives in
>>     modules/.../keycloak-wildfly-subsystem/main/auth-server.  By
>>     default, it is unexploded.  If you want it to be exploded you can
>>     unzip it into that same directory and set the
>>     "auth-server-exploded" property in module.xml.
>>   * A new Auth Server is declared in standalone.xml/domain.xml.  You
>>     can have more than one Auth Server in the same WildFly instance.
>>   * <subsystem xmlns="urn:jboss:domain:keycloak:1.0">
>>                 <auth-server name="main-auth-server">
>>                     <enabled>true</enabled>
>>                     <web-context>auth</web-context>
>>                 </auth-server>
>>
>>   * The "enabled" attribute can be toggled at runtime to make the
>>     auth server undeploy/redeploy.
>>   * If you have more than one auth-server, the web-context must be
>>     unique.
>>   * In a domain environment, all specified Auth Server deployments
>>     are propagated to all servers using that profile.  The same is
>>     true for overlays uploaded through the new CLI operations.
>>   * There are two new CLI operations that act on an auth-server. 
>>     They are "add-provider" and "update-server-config".  Currently,
>>     you can only execute these operations in the latest version of
>>     CLI GUI.   We should discuss if we need to add support in plain
>>     CLI.  The long term goal would be to add this functionality to
>>     the Keycloak Admin Console.
>>   * "add-provider" adds a provider jar to an auth-server
>>   * "update-server-config" overlays the keycloak-server.json for an
>>     auth-server.
>>   * If a keycloak-server.json file is found in
>>     standalone/configuration directory, all auth-server instances
>>     will still use it regardless of any update-server-config operations.
>>   * EAP6 does not yet support all this.  We should discuss whether or
>>     not this functionality should be backported.
>>
>>
>>
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20141101/4a08e758/attachment-0001.html