[keycloak-dev] Programatic configuration

Marek Posolda mposolda at redhat.com
Fri Nov 28 03:37:05 EST 2014


Hi Bruno,

On 27.11.2014 18:36, Bruno Oliveira wrote:
> Hi Marek, after trying your approach and several combinations. I'm
> really not sure if that applies for JS clients. Currently I'm getting
> https://gist.github.com/abstractj/ef42e28903e470d5033d.
You mean replacing system properties? This doesn't apply for JS clients. 
If you have something like this in your webapp:

var keycloak = new Keycloak('config/admin-ui-keycloak.json');

and in file src/main/webapp/config/admin-ui-keycloak.json you have 
something like:

"auth-server-url" : "${keycloak.url}",

it won't be replaced.

Replacing system properties is done programatically by keycloak and it 
applies only for adapter configs parsed by KeycloakDeploymentBuilder spi 
(this works just in latest KC master due to this 
https://github.com/keycloak/keycloak/blob/master/integration/adapter-core/src/main/java/org/keycloak/adapters/KeycloakDeploymentBuilder.java#L95) 
or if you do it manually for some property in AdapterConfig like you did 
for authServerUrl in KeycloakBootstrapListener.


If you want replacing system properties for JS adapter configuration, 
you may need something like Proxy servlet, which will do it in java code 
for you. So for example in app.js you will have something like:

var keycloak = new Keycloak('keycloak-client-config');

And path '/keycloak-client-config' will be mapped in web.xml to this 
servlet. Servlet will then parse the adapter json file to AdapterConfig 
(or create it programmatically if you want), then replace system 
properties and then send back JSON with adapter config with system 
properties replaced. Is this an option for you?

Marek

>
> My servlet listener was configured like you suggested
> https://github.com/abstractj/aerogear-unifiedpush-server/commit/d5298d613a6bbb80d2c72b8514f353270c59cc76#diff-9f3da7bef7f5073aaa7dc3c851f539a1R31.
> The adapter related to the JS side was commented once I noticed no
> effect on leave uncommented.
>
> Also I moved my configuration on the client side to
> https://github.com/abstractj/aerogear-unifiedpush-server/commit/d5298d613a6bbb80d2c72b8514f353270c59cc76#diff-e0ab405f82ed2d1fc13835905c83b4bcR25.
> If you leave the constructor empty keycloak.js will look for
> keycloak.json. Btw I tried several combinations, but no luck.
>
> I think I'm close, not sure how long to figure this out.
>
> On 2014-11-26, Marek Posolda wrote:
>> Good morning Bruno, if you are using it like in this code snippet (in other
>> words, AdapterConfig is created programmatically by calling java setters)
>> then maybe easiest is to use just something like this:
>>
>> config.setAuthServerUrl(StringPropertyReplacer.replaceProperties("${keycloak.url}");
>>
>> StringPropertyReplacer is already available in KC 1.0 codebase, so you
>> should be ok to use it like this even on KC 1.0.
>>
>> Otherwise if you create AdapterConfig from parsing the json file with
>> jackson-mapper like it's done in our KeycloakDeploymentBuilder, you may need
>> to add SystemPropertiesJsonParserFactory to be added into constructor of
>> particular ObjectMapper. If you can upgrade to 1.1.0.Beta1, you don't need
>> to fork anything as class is available in KC codebase. If you still need to
>> be on 1.0 for some time, then you probably need to fork it.
>>
>> Marek
>>
>> On 26.11.2014 06:59, Bruno Oliveira wrote:
>>> Good morning Marek, I was using it like mentioned before
>>> https://gist.github.com/abstractj/bc238623e79d030d37a6. But removed
>>> that later. Currently I'm running KC beta1 and I'm fine on forking/make
>>> use of it, just not sure if its the recommended way.
>>>
>>> Thanks in advance.
>>>
>>> On 2014-11-25, Marek Posolda wrote:
>>>> How exactly are you creating AdapterConfig? To replace system properties,
>>>> you may need to use SystemPropertiesJsonParserFactory similarly like is used
>>>> here: https://github.com/keycloak/keycloak/blob/master/integration/adapter-core/src/main/java/org/keycloak/adapters/KeycloakDeploymentBuilder.java#L95
>>>>
>>>> Note that replacing system props in adapter config was added in keycloak
>>>> 1.1.0.Beta1 (as prerequisite to clustering support), but I guess that you
>>>> guys are still on KC 1.0 ? If it's the case, you can maybe fork the
>>>> SystemPropertiesJsonParserFactory to your env and create ObjectMapper with
>>>> passing it as an argument?
>>>>
>>>> Marek
>>>>
>>>> On 25.11.2014 20:12, Bruno Oliveira wrote:
>>>>> I might be missing something, here is my attempt:
>>>>>
>>>>> [standalone at localhost:9990 /] /system-property=keycloak.url:add(value="http://10.0.1.7/auth")
>>>>> {"outcome" => "success"}
>>>>>
>>>>> or
>>>>>
>>>>> public class UpsKeycloakApplication extends KeycloakApplication {
>>>>>      public UpsKeycloakApplication(@Context ServletContext context, @Context Dispatcher dispatcher) {
>>>>>          super(context, dispatcher);
>>>>>          System.setProperty("keycloak.url", "http://10.0.1.7/auth");
>>>>>      }
>>>>> }
>>>>>
>>>>> JSON files:
>>>>>
>>>>> - keycloak.json
>>>>>
>>>>> {
>>>>>    "realm" : "aerogear",
>>>>>    "auth-server-url" : "${keycloak.url}",
>>>>>    "ssl-required" : "external",
>>>>>    "resource" : "unified-push-server",
>>>>>    "bearer-only" : true,
>>>>>    "disable-trust-manager" : true
>>>>> }
>>>>>
>>>>> - admin-ui-keycloak.json
>>>>>
>>>>>
>>>>> {
>>>>>      "realm" : "aerogear",
>>>>>      "auth-server-url" : "${keycloak.url}",
>>>>>      "ssl-required" : "external",
>>>>>      "resource" : "unified-push-server-js",
>>>>>      "public-client" : true
>>>>> }
>>>>>
>>>>>
>>>>> Exception:
>>>>>
>>>>> 17:07:38,649 ERROR [org.jboss.as.controller.management-operation] (DeploymentScanner-threads - 2) JBAS014613: Operation ("deploy") failed - address: ([("deployment" => "ag-push.war")]) - failure description: {"JBAS014671: Failed services" => {"jboss.undertow.deployment.default-server.default-host./ag-push" => "org.jboss.msc.service.StartException in service jboss.undertow.deployment.default-server.default-host./ag-push: Failed to start service
>>>>>      Caused by: java.lang.IllegalArgumentException: Illegal character in path at index 1: ${keycloak.url}
>>>>>      Caused by: java.net.URISyntaxException: Illegal character in path at index 1: ${keycloak.url}"}}
>>>>>
>>>>>
>>>>> I also tried to make use of keycloak.auth-sever available here
>>>>> https://github.com/keycloak/keycloak/blob/master/integration/wildfly-subsystem/src/main/resources/org/keycloak/subsystem/extension/LocalDescriptions.properties. But got the same exception.
>>>>>
>>>>>
>>>>> On 2014-11-25, Stian Thorgersen wrote:
>>>>>> ----- Original Message -----
>>>>>>> From: "Bruno Oliveira" <bruno at abstractj.org>
>>>>>>> To: "Bill Burke" <bburke at redhat.com>
>>>>>>> Cc: keycloak-dev at lists.jboss.org
>>>>>>> Sent: Tuesday, 25 November, 2014 2:35:58 PM
>>>>>>> Subject: Re: [keycloak-dev] Programatic configuration
>>>>>>>
>>>>>>> Double checking to see if my understanding is correct. On UPS realm we
>>>>>>> have 2 applications:
>>>>>>>
>>>>>>> "applications": [
>>>>>>>          {
>>>>>>>              "name": "unified-push-server",
>>>>>>>              "enabled": true,
>>>>>>>              "bearerOnly": true
>>>>>>>          },
>>>>>>>          {
>>>>>>>              "name": "unified-push-server-js",
>>>>>>>              "enabled": true,
>>>>>>>              "publicClient": true,
>>>>>>>              "baseUrl": "/ag-push",
>>>>>>>              "redirectUris": [
>>>>>>>                  "http://localhost:8080/ag-push/*"
>>>>>>>              ]
>>>>>>>          }
>>>>>>>      ]
>>>>>>>
>>>>>>> The only resource which requires to be modified dinamically is
>>>>>>> unified-push-server-js. So making
>>>>>>> use of servlet listeners like Bill did in the past for UPS we have:
>>>>>>>
>>>>>>> AdapterDeploymentContext deploymentContext = (AdapterDeploymentContext)
>>>>>>> sce.getServletContext().getAttribute(AdapterDeploymentContext.class.getName());
>>>>>>> AdapterConfig config = new AdapterConfig();
>>>>>>> config.setRealm("aerogear");
>>>>>>> //Dinamically replaced
>>>>>>> config.setRealmKey("MIGfMA0GCSqGSIb3DQEBAQUAA");
>>>>>>> //Dinamically replaced
>>>>>>> config.setAuthServerUrl("http://mydomain.com:8081/auth");
>>>>>>> config.setResource("unified-push-server-js");
>>>>>>> config.setSslRequired("external");
>>>>>>> config.setPublicClient(true);
>>>>>>> deploymentContext.updateDeployment(config);
>>>>>>>
>>>>>>> Into this way we can remove unified-push-server-js from ups-realm.json,
>>>>>>> right? One thing not totally clear is about Keycloak.js. Currently we
>>>>>>> have something like:
>>>>>>>
>>>>>>> Keycloak kc = new Keycloak('config/keycloak.json')
>>>>>>>
>>>>>>> With the changed mentioned above, the JSON file is still required? Or
>>>>>>> not necessary?
>>>>>> I don't see any point in having all of that, just use the keycloak.json with a system property for the auth-server url. The realm keys are automatically downloaded so no need to specify those.
>>>>>>
>>>>>>> On 2014-11-25, Bill Burke wrote:
>>>>>>>> On 11/25/2014 7:50 AM, Stian Thorgersen wrote:
>>>>>>>>> ----- Original Message -----
>>>>>>>>>> From: "Bruno Oliveira" <bruno at abstractj.org>
>>>>>>>>>> To: "Stian Thorgersen" <stian at redhat.com>
>>>>>>>>>> Cc: "keycloak dev" <keycloak-dev at lists.jboss.org>
>>>>>>>>>> Sent: Tuesday, 25 November, 2014 1:29:24 PM
>>>>>>>>>> Subject: Re: [keycloak-dev] Programatic configuration
>>>>>>>>>>
>>>>>>>>>> On 2014-11-25, Stian Thorgersen wrote:
>>>>>>>>>>> ----- Original Message -----
>>>>>>>>>>>> From: "Bruno Oliveira" <bruno at abstractj.org>
>>>>>>>>>>>> To: "keycloak dev" <keycloak-dev at lists.jboss.org>
>>>>>>>>>>>> Sent: Tuesday, 25 November, 2014 12:22:22 PM
>>>>>>>>>>>> Subject: [keycloak-dev] Programatic configuration
>>>>>>>>>>>>
>>>>>>>>>>>> Good morning, we've been discussing the following workflow on
>>>>>>>>>>>> AeroGear:
>>>>>>>>>>>>
>>>>>>>>>>>> First time
>>>>>>>>>>>>
>>>>>>>>>>>> 1. Developer create an UPS instance on OpenShift
>>>>>>>>>>>> 2. Visit https://myups-abstractj.rhcloud.com/ag-push
>>>>>>>>>>>> 3. The application automagically redirect to the configuration page
>>>>>>>>>>>> the
>>>>>>>>>>>> with
>>>>>>>>>>>> options default or Custom — where default make use of the embbeded
>>>>>>>>>>>> Keycloak on UPS and custom our developer would be able to specify
>>>>>>>>>>>> another Keycloak instance (http://andresgalante.com/configuration/)
>>>>>>>>>>>> 4. App changes the keycloak.json/ups-realm.json file based on the URL
>>>>>>>>>>>> provided.
>>>>>>>>>>>>
>>>>>>>>>>>> Second time
>>>>>>>>>>>>
>>>>>>>>>>>> 1. Visit https://myups-abstractj.rhcloud.com/ag-push
>>>>>>>>>>>> 2. The application check if some configuration already exists (default
>>>>>>>>>>>> or custom)
>>>>>>>>>>>> 3. Redirect users to UPS login page or Keycloak login page. It pretty
>>>>>>>>>>>> much depends.
>>>>>>>>>>>>
>>>>>>>>>>>> I would like to programatically change (via Java) `ups-realm.json`,
>>>>>>>>>>>> `keycloak.json`
>>>>>>>>>>>> and `admin-ui-keycloak.json`. See
>>>>>>>>>>>> https://github.com/abstractj/aerogear-unifiedpush-server/commit/e8fc8461fea69801cc495127a88aff05a55c68cd#diff-356b0e49e775810162fd2be9110bb5f4R3
>>>>>>>>>>>>
>>>>>>>>>>>> Possible alternatives off the top of my head:
>>>>>>>>>>>>
>>>>>>>>>>>> 1. Read/manipulate JSON files from the database and provide
>>>>>>>>>>>> `keycloak.json`
>>>>>>>>>>>> and
>>>>>>>>>>>> `admin-ui-keycloak.json` as a resource like Keycloak team did for
>>>>>>>>>>>> JavaScript
>>>>>>>>>>>> https://github.com/keycloak/keycloak/blob/master/services/src/main/java/org/keycloak/services/resources/JsResource.java
>>>>>>>>>>>> 2. Dinamically generate to a shared place on WildFly `keycloak.json`
>>>>>>>>>>>> and
>>>>>>>>>>>> `admin-ui-keycloak.json` files.
>>>>>>>>>>>>
>>>>>>>>>>>> Do you have a better idea?
>>>>>>>>>>> Is it only the auth-server url you're changing? keycloak.json supports
>>>>>>>>>>> system properties so you can use for example { "auth-server" :
>>>>>>>>>>> "${keycloak.url}" }. If you do that you don't have to rewrite the file
>>>>>>>>>>> at
>>>>>>>>>>> all.
>>>>>>>>>> Yes! That's gorgeous! Am I supposed to define it during the bootstrap?
>>>>>>>>>> For ups-realm.json file, I'm considering to make use of
>>>>>>>>>> AdapterDeploymentContext like we did in the past, because the redirect
>>>>>>>>>> url must dinamically change
>>>>>>>>>> https://github.com/abstractj/aerogear-unifiedpush-server/commit/e8fc8461fea69801cc495127a88aff05a55c68cd#diff-b8df82f22499b0118c37e0e363c4342aR80
>>>>>>>>> How would AdapterDeploymentContext work for a remote KC server?
>>>>>>>>>
>>>>>>>>> In the past I had an idea of adding support for server aliases, so you
>>>>>>>>> could for example do "http://${ups}/ag-push" as the redirect-uri in KC.
>>>>>>>>> Then we could provide some easy way to manage server-aliases, even
>>>>>>>>> allowing it to resolve to one or more urls.
>>>>>>>>>
>>>>>>>> The idea was that the UPS mgmt console would allow you to specify a
>>>>>>>> remote keycloak URL.  It would store this URL, then update the
>>>>>>>> AdapterDeploymentContext at runtime.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> 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
>>>>>>> --
>>>>>>>
>>>>>>> abstractj
>>>>>>> PGP: 0x84DC9914
>>>>>>> _______________________________________________
>>>>>>> keycloak-dev mailing list
>>>>>>> keycloak-dev at lists.jboss.org
>>>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>> --
>>>>>
>>>>> abstractj
>>>>> PGP: 0x84DC9914
>>>>> _______________________________________________
>>>>> keycloak-dev mailing list
>>>>> keycloak-dev at lists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>> --
>>>
>>> abstractj
>>> PGP: 0x84DC9914
> --
>
> abstractj
> PGP: 0x84DC9914



More information about the keycloak-dev mailing list