Re: [keycloak-dev] WildFly subsystem and demo

----- Original Message ----- > From: "Bill Burke" <bburke(a)redhat.com&gt; > To: keycloak-dev(a)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.

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