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

Brian Stansberry brian.stansberry at redhat.com
Mon Jul 13 10:38:21 EDT 2015


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.

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


More information about the wildfly-dev mailing list