[keycloak-dev] WildFly subsystem and demo

[Bill Burke]

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
http://bill.burkecentral.com