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

[Stian Thorgersen]

----- Original Message -----
> From: "Brian Stansberry" <brian.stansberry at redhat.com>
> To: wildfly-dev at 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 at redhat.com>
> >> To: "Stian Thorgersen" <stian at redhat.com>
> >> Cc: "keycloak dev" <keycloak-dev at lists.jboss.org>,
> >> wildfly-dev at 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 at redhat.com> 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.

We can't depend on JDK 8 for our core library as it's used by our other adapters. So I guess our best option is to copy/paste in that case.

> 
> >>
> >>>
> >>> 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 at lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/wildfly-dev
> >
> > _______________________________________________
> > wildfly-dev mailing list
> > wildfly-dev at 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 at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev