[keycloak-dev] WildFly subsystem and demo

Bill Burke bburke at redhat.com
Tue Feb 18 11:10:12 EST 2014

On 2/18/2014 11:00 AM, Stian Thorgersen wrote:
> ----- Original Message -----
>> From: "Bill Burke" <bburke at redhat.com>
>> To: keycloak-dev at lists.jboss.org
>> Sent: Tuesday, 18 February, 2014 3:53:38 PM
>> Subject: Re: [keycloak-dev] WildFly subsystem and demo
>> On 2/18/2014 10:47 AM, Stan Silvert wrote:
>>> On 2/18/2014 9:45 AM, Bill Burke wrote:
>>>> On 2/18/2014 7:44 AM, Stan Silvert wrote:
>>>>> On 2/18/2014 7:16 AM, Stian Thorgersen wrote:
>>>>>> I've just tried out deploying the demo manually using the WildFly
>>>>>> subsystem. It's very cool and I really like how the WildFly subsystem
>>>>>> has made things so much simpler. Some comments though on my
>>>>>> "experience" trying this out.
>>>>>> 1. Having to edit standalone.xml to add secure-deployment requires
>>>>>> restarting the server. In installation tab we could have an additional
>>>>>> option that lists the jboss-cli command to add this at runtime
>>>>> Yes, it's usually easier and more accurate to run a CLI script instead
>>>>> of editing standalone.xml by hand.  Using CLI also allows you to make
>>>>> the update remotely when you might not have access to the remote file
>>>>> system.
>>>> Stan.  I actually kinda (not wholeheartedly) disagree.  To run the CLI
>>>> requires setting up a local user to administrate the server.  Its
>>>> actually easier to cut, paste, and restart, IMO.
>>> If you are local then CLI does not require setting up a user.  Web
>>> console requires it, but CLI does not.
>>> If you are remote then I'm sure you agree that CLI is better since it is
>>> that much harder to edit a remote file.
>> I just can't see (yet) anybody securing a system remotely.  Even in the
>> Openshift case, its a real pain to do anything with a subsystem remotely
>> as you have to do port mapping to expose the admin HTTP interface, and
>> also set up a admin user (which I don't think can be done without
>> hardcoding initial credentials).
> The WF cartridge we forked actually creates a admin user and prints out the username/password when you first create it. Not sure if the "official" WF cartridge does the same though.

So you can have a custom "install script" for a cartridge that runs? 
That makes things easier.  But you still have to set up port mapping to 
expose the admin ports.

> One solution could be to have "deployable" config files in the same way as you can put "-ds.xml" files in standalone/deployment. That could be simpler for OpenShift at least. Basically you'd:
> 1. Create KC cartridge
> 2. Open admin console, create the app, download a "myapp-keycloak.xml"
> 3. Add "myapp-keycloak.xml" and your war to deployments and git push to redeploy it

Why wouldn't you just crack open the war and put in keycloak.json?

We need to figure out bootstrapping for Aerogear.  That is a separate 
email thread I started a week or so ago.  This is a case where the app 
being secured by keycloak is based on Wildfly, but you don't want to 
require the admins to actually know it is based on wildfly.

Bill Burke
JBoss, a division of Red Hat

More information about the keycloak-dev mailing list