Re: [wildfly-dev] Including Keycloak client adapters in WildFly 10

From: "Brian Stansberry" <brian.stansberry(a)redhat.com&gt; To: wildfly-dev(a)lists.jboss.org Sent: Monday, 13 July, 2015 4:38:21 PM Subject: Re: [wildfly-dev] Including Keycloak client adapters in WildFly 10 On 7/13/15 9:34 AM, Stian Thorgersen wrote: > > ----- Original Message ----- >> From: "Jason Greene" <jason.greene(a)redhat.com&gt; >> To: "Stian Thorgersen" <stian(a)redhat.com&gt; >> Cc: "keycloak dev" <keycloak-dev(a)lists.jboss.org&gt;, >> wildfly-dev(a)lists.jboss.org >> Sent: Tuesday, 7 July, 2015 11:19:52 PM >> Subject: Re: [wildfly-dev] Including Keycloak client adapters in WildFly >> 10 >> >> >>> On Jul 3, 2015, at 6:40 AM, Stian Thorgersen <stian(a)redhat.com&gt; wrote: >>> >>> Keycloak provides an adapter, including a WildFly extensions, to make it >>> easier to add authentication to JavaEE applications with Keycloak. >> >> Sorry for my delay replying. Comments are inline: >> >>> >>> It includes a few modules. Currently 8 Keycloak specific modules and one >>> 1 >>> third-party. The third-party is net.iharder.base64. >> >> We already have many Base64 implementations. It’s pretty easy to pull one >> in >> with cut and paste. Java 8 also provides one, so that could be used. > > We can copy/paste it, but would it not be better to include one Base64 lib > in WildFly than have everyone have their own? > Since WildFly 10 requires JDK 8, it uses the JDK one.

>> >>> >>> As the WildFly extensions includes a deployment processor that configures >>> the authentication method as well as dependencies for a deployment it's >>> easy to add authentication to a JavaEE application. All you need to do is >>> specify it in standalone.xml, for example: >>> >>> ... >>> <secure-deployment name="mywar.war”> >> >> I’m assuming that the DUPs you register match the deployment name with >> this >> key, and then modify the app configuration? > > Yep > >> >>> <realm>myrealm</realm> >>> <realm-public-key>MIIBIjAN...</realm-public-key> >>> <auth-server-url>http://localhost:8081/auth</auth-server-url> >>> <ssl-required>EXTERNAL</ssl-required> >>> <resource>mywar</resource> >>> <credential >>> name="secret">675356d8-2b6b-4602-a74f-7079e0555885</credential> >> >> You probably already did this, but such an attribute should support vault >> usage as well so that credentials can be kept out of configs. > > No, pretty sure we don't, but we should > >> >>> </secure-deployment> >>> ... >>> >>> I'd like to explore if we can add this extension and the required modules >>> directly to WildFly 10, rather than require users to add it themselves. >> >> Can you sync up with the elytron team? They are making other changes in >> this >> area, which are not yet in 10, and I want to make sure thats all >> compatible. > > Will do, we need to have a sync with them asap in either case to make sure > the Elytron SPIs cover all use-cases we need. > >> >> -- >> Jason T. Greene >> WildFly Lead / JBoss EAP Platform Architect >> JBoss, a division of Red Hat >> >> >> _______________________________________________ >> wildfly-dev mailing list >> wildfly-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/wildfly-dev > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > -- Brian Stansberry Senior Principal Software Engineer JBoss by Red Hat _______________________________________________ wildfly-dev mailing list wildfly-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/wildfly-dev