2:49 p.m.
On Thu, Jan 30, 2014 at 2:45 PM, Bill Burke <bburke(a)redhat.com> wrote:
The admin console has a REST API that you can use directly to
configure
your realm and applications if you need.
Without a Wildfly subsystem, keycloak.json is required to get the public
key and your client credentials.
The wildfly subsystem will remove the need for cracking open a WAR. The
initial implementation may be a little clumsy at first, but I think
there's a huge amount we can do to make it real easy to use.
that (wildfly subsystem) pretty much sounds like what we would want to use
for an integration of the UnifiedPush Server and Keycloak.
I don't care that much if it is a bit clumsy at first, since we can always
improve it later; Most benefit of using the subsystem, for us, will be
getting rid of the keycloak.json requirement
-Matthias
On 1/30/2014 8:30 AM, Matthias Wessendorf wrote:
> Hello there!
>
>
> For the AeroGear UnifiedPush Server Bruno and I started looking at
> Keycloak ([1]). On this branch, we basically include the adapater jar
> and a keycloak.json file and simply rely on Keycloak as an external
> service (e.g. as different WAR inside of the same containter). That
> works very well so far!!
> However, here I have to create a realm in the server (either via
> Admin-Console or by including it via something like 'myRealm.json') and
> afterwards I have to 'hard-code' the public key into my own WAR file
> (keycloak.jso):
>
>
https://github.com/aerogear/aerogear-unifiedpush-server/blob/keycloak/src...
>
> So this would be a little bit of a negative effect;
>
>
>
> Another option would be embedding the Keycloak JARs into my own WAR
> file, by adding all the dependent JARs, similiar to what the
> 'keycloak-server' does ([2]). At the end I'd have an uber WAR file,
> containing UPS and Keycloak facilities. However, I think the 'problem'
> w/ the 'hard-code' key inside of the keycloak.json would be there as
> well, right ?
>
>
>
> On the IRC channel Stian mentioned that there will be a WildFly
> subsystem soon. I think, from what I hear, the real benefit of this
> subsystem are the following items:
>
> * configuring realms through standalone.xml
> * automatically sets up security for wars (using the wildfly adapter)
>
> So, this option seems to let us avoid the above described keycloak.json
> 'issue', right ?
>
> For a future integration w/ the Keycloak SSO server, I could leverage
> the Subsystem deliverables and bundle them w/ our own UnifiedPush Server
> distribution, to ensure things are running out of the box; Or is the
> subsystem not the best option for a Push/Keycloak integration ?
>
>
>
> -Matthias
>
>
> [1]
https://github.com/aerogear/aerogear-unifiedpush-server/tree/keycloak
> [2] https://github.com/keycloak/keycloak/blob/master/server/pom.xml
>
> --
> Matthias Wessendorf
>
> blog: http://matthiaswessendorf.wordpress.com/
> sessions: http://www.slideshare.net/mwessendorf
> twitter: http://twitter.com/mwessendorf
>
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
--
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
--
Matthias Wessendorf
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf