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

2. Customer portal error messages are horrible at best. First I forgot to deploy the database services, which caused the exception "Unexpected character ('<' (code 60)): expected a valid value (number, String, array, object, 'true', 'false' or 'null')". This should have probably been something like "Database services not found". Then I deployed database services, but used the wrong WAR name in the secure-deployment and the error message was the same, but should have been "Unauthorized". 3. Finally, it's not clear enough in the log output when the Keycloak sub-system acts on a deployment and when it doesn't. We definitively need something along the lines of: INFO [org.keycloak.wildfly] Keycloak configured for 'customer-portal.war'

Could also be an idea to add (not sure if it should be info or debug): DEBUG [org.keycloak.wildfly] Ignoring 'customer-portal.war'

_______________________________________________ keycloak-dev mailing list keycloak-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-dev

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.

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

> 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(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-dev

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

> Customer portal error messages are horrible at best. First I forgot to deploy the database services, which caused the exception "Unexpected character ('<' (code 60)): expected a valid value (number, String, array, object, 'true', 'false' or 'null')". This should have probably been something like "Database services not found". Then I deployed database services, but used the wrong WAR name in the secure-deployment and the error message was the same, but should have been "Unauthorized". > > Long standing issue. I'll fix that.