[keycloak-dev] require adapter modules?

[ssilvert at redhat.com]

An update on the subsystem:

If a deployment is listed in the subsystem, it automatically adds the
org.keycloak.adapter module as a dependency of the deployment.  No
jboss-deployment-structure.xml is needed.

When we install the org.keycloak.adapter module, let's install the
subsystem at the same time.  However, while the subsystem is almost
working, it probably won't be ready for this first release.

In the future, I think keycloak modules and the subsystem will be
included in the WildFly/EAP distribution.  You won't be required to have
anything keycloak-related in your WAR.  You just add keycloak to your
deployment from the keycloak UI or from JBoss CLI.

Soon, we need to start telling people to stop putting authentication
into their applications.  Authentication is a cross-cutting concern that
should be 100% decoupled from the app.  I think that's a killer
message.  Developers don't need to worry about authentication any more.

BTW, I'm not sure if the module solution will work for EAP6.  Have you
tried using a keycloak module on EAP6?  When I tried it I ran into some
classloading problems initializing the OAuthAuthenticatorValve.  I also
tried using a global valve[1].  Global valve worked better, but I found
that JBoss Web is not calling LifecycleListener methods for global
valves.  Some more investigation needs to be done.

[1] https://community.jboss.org/wiki/AddAGlobalValveInAS772x

On 1/3/2014 7:42 PM, Bill Burke wrote:
> Rather than have multiple options for installing a as7 or wildfly 
> adapter, do you think its fine to require the installation of jboss 
> modules for your desired adapter then adding a 
> jboss-deployment-structure.xml to your deployment?
>
> * This avoids any dependency conflict between a keycloak adapter and the 
> application.
> * The distribution becomes smaller as I don't have to include both 
> jboss-modules zips and unpacked jars.
> * Less options is also less confusing.  Having too many options can be 
> confusing
> * We can always document later how to pull in libs directly to the 
> deployment.
>
>