[keycloak-dev] WildFly subsystem and demo

[Stian Thorgersen]

----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: "Stian Thorgersen" <stian at redhat.com>
> Cc: keycloak-dev at lists.jboss.org
> Sent: Tuesday, 18 February, 2014 4:10:12 PM
> Subject: Re: [keycloak-dev] WildFly subsystem and demo
> 
> 
> 
> 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.

Yes, it's just a bunch of bash scripts. I was going to use this as a way of automatically configuring the db. When you create KC you can choose to add the MySQL or PostgreSQL add-on cartridges, and on first startup it would detect if one is available and automatically re-configure the db.

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

Because you need to crack it open. Also, for the future if you change the config in KC, or you make some updates to your war, you're required to do it again.

IMO config should never ever be inside a WAR ;)

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