Hi Marek, after trying your approach and several combinations. I'm
really not sure if that applies for JS clients. Currently I'm getting
.
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
.
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...
>>
>>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-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(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/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(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