6:42 p.m.
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.
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
2:42 p.m.
+1
For the subsystem, I'm using a single module called
"org.keycloak.adapter". It contains the three keycloak jars and lists
dependencies. I'm attaching the modules.xml for WildFly so you can see
what I've done.
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.
2:48 p.m.
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.
4004
days inactive
4004
days old
2 comments
2 participants
participants (2)
-
Bill Burke -
ssilvert＠redhat.com