[keycloak-dev] Keycloak Integration Options (with UnifiedPush Server)

[Matthias Wessendorf]

On Thu, Jan 30, 2014 at 2:45 PM, Bill Burke <bburke at 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/main/webapp/WEB-INF/keycloak.json#L3
> >
> > 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 at 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 at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20140130/4c08db40/attachment.html