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.

> > 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?

> <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.

> </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.

-- 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

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