[keycloak-dev] WildFly subsystem and demo

Stian Thorgersen stian at redhat.com
Tue Feb 18 11:00:04 EST 2014



----- 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.

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

> 
> > Granted, there is more work to do in this area to make it even easier.
> > One thing you could do is create a CLI script along with a *.sh or *.bat
> > file to launch it.  Tell the user to save it to JBOSS_HOME/bin.  Then
> > you can update the server quickly and accurately with a single click.
> 
> Or, they could just cut and paste the XML from the admin console to
> standalone.xml...which is, still...IMO...faster, simpler, and easier?
> 
> 
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> 


More information about the keycloak-dev mailing list