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...
>
> 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@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-subs....
But got the same exception.
>>
>>
>> On 2014-11-25, Stian Thorgersen wrote:
>>> ----- Original Message -----
>>>> From: "Bruno Oliveira" <bruno(a)abstractj.org>
>>>> To: "Bill Burke" <bburke(a)redhat.com>
>>>> Cc: keycloak-dev(a)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(a)abstractj.org>
>>>>>>> To: "Stian Thorgersen" <stian(a)redhat.com>
>>>>>>> Cc: "keycloak dev"
<keycloak-dev(a)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(a)abstractj.org>
>>>>>>>>> To: "keycloak dev"
<keycloak-dev(a)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/e8fc8461f...
>>>>>>>>>
>>>>>>>>> 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/o...
>>>>>>>>> 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/e8fc8461f...
>>>>>> 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(a)lists.jboss.org
>>>>>
https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>> --
>>>>
>>>> abstractj
>>>> PGP: 0x84DC9914
>>>> _______________________________________________
>>>> keycloak-dev mailing list
>>>> keycloak-dev(a)lists.jboss.org
>>>>
https://lists.jboss.org/mailman/listinfo/keycloak-dev
>> --
>>
>> abstractj
>> PGP: 0x84DC9914
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev(a)lists.jboss.org
>>
https://lists.jboss.org/mailman/listinfo/keycloak-dev
--
abstractj
PGP: 0x84DC9914