Maven upgrade coming
by Tomaž Cerar
Hey guys,
Just bit of heads up, we are moving build to require maven 3.2.1
This will bring us munch awaited feature of * exclusion of transitive
dependencies.
for more see http://maven.apache.org/docs/3.2.1/release-notes.html
If you don't use maven provided in source tree, you should upgrade,
as you wont be able to build anymore as soon as PR is merged.
--
tomaz
9 years, 10 months
Keycloak SSO in WildFly 9
by Stan Silvert
In response to Jason's request for design proposals on this list, here
is the proposal for Keycloak SSO in WildFly 9.
Background
-----------------
A major part of our console unification effort is to allow various JBoss
management consoles to take advantage of Single Signon. To achieve this
end, Keycloak SSO[1] will be integrated into the WildFly 9 platform.
The first management consoles to use Keycloak will likely be the WildFly
Web Console[2] and the JON Console.
Proof of Concept
-----------------------
A hacked-up proof of concept is available at
https://github.com/ssilvert/wildfly/tree/kcauth. It demonstrates a
WildFly standalone server using Keycloak for both authentication and
authorization in the Web Console. It also shows single signon between
the Web Console and the Keycloak Admin application. See
https://github.com/ssilvert/wildfly/blob/kcauth/keycloak/KeycloakSetup.txt
for details.
One interesting finding of the POC is that the Keycloak integration
required no changes to the WildFly Web Console. All the integration is
done on the server side and the GWT client works perfectly as-is.
Relation to the Elytron and other WildFly 9 changes
------------------------------------------------------------------------
Keycloak is expected to use Elytron at a low level. Nothing at the
Keycloak integration level should be affected by the Elytron project.
However, there are many other expected changes to security that may
effect how Keycloak is integrated. It is likely that the initial
integration of Keycloak will happen before these aforementioned
changes. This will be an advantage as the unit tests for Keycloak
integration can help to validate these changes.
Default Authentication Mechanism
------------------------------------------------
Keycloak is a very new technology. Given that security is so vital, we
need time for Keycloak to mature. When Keycloak is first integrated, it
will not be the default authentication/authorization mechanism for the
WildFly Web Console. However, selecting Keycloak for authentication
should be as simple as executing one or two CLI commands.
We can switch to Keycloak as the default whenever we all believe that
both Keycloak itself and its integration into WildFly are ready for
prime time. Hopefully, that will just be a matter of months after first
integration.
Initial Integration
------------------------
The initial integration for most of Keycloak will only be available on
standalone. However, on a domain controller, the WildFly Web Console
will still be able to use Keycloak for authentication and
authorization. In this case, the domain controller must be able to
reach a Keycloak Authentication Server somewhere on the network.
Keycloak Authentication Server and Admin Console
-----------------------------------------------------------------------
The Keycloak Authentication Server is responsible for authenticating and
authorizing users. The Keycloak Admin Console is an AngularJS UI that
administrators use to manage users, roles, sessions, passwords, assigned
applications, etc.
Both the auth server and admin console are served from the same WAR. It
should be possible to deploy this without using a WAR or servlets, but
that is not planned for the initial WildFly integration. Because of
this current limitation, the auth server and admin console will not be
present in a domain controller.
Keycloak Database
--------------------------
The Keycloak database contains all the server-side configuration data
such as the data manipulated by the Keycloak Admin Console. By default,
it is an H2 database that lives in the standalone/data directory. It is
created when the auth server is first deployed.
This database will be initialized with a single "admin" user who has all
rights within the Keycloak Admin Console and within the WildFly Web
Console. On first login, the admin user must change his password.
By default, both consoles will be in the same master realm so that users
can potentially do single signon and move freely between them.
H2 is not recommended for production use. Keycloak has tools available
to migrate data to another database.
Keycloak Adapter
------------------------
A Keycloak adapter is a bit of software that is attached to an
application deployment. This software knows how to talk to the Keycloak
auth server. It handles the OAuth protocol from the client side.
In the case of the WildFly Web Console, the adapter will be a pure
Undertow, non-servlet adapter. The reason for using a pure Undertow
adapter instead of the current Keycloak WildFly adapter is that the
latter adapter relies on the Servlet API, which is forbidden on a domain
controller. The proof of concept mentioned above contains the code
needed for a pure Undertow adapter. This code will likely be migrated
into the Keycloak project.
Keycloak Adapter Configuration
-------------------------------------------
A Keycloak adapter configuration is a json or DMR representation of an
application's client-side Keycloak configuration. It is used by the
adapter to find data such as public keys and the location of the auth
server. (From the POC, see master->Applications->web-console->Installation)
In the case of WildFly Web Console, we actually have two application
endpoints that need to be configured and protected by Keycloak. These
are the GWT-based UI and the http management endpoint that accepts DMR
operations. The Keycloak configuration for these applications will live
in the DMR management tree under SuperUser access. This restrictive
access only applies to the Keycloak adapter configuration. Any RBAC
role can be assigned to a user of the WildFly Web Console via the
Keycloak Admin Console.
Note that the proof of concept still uses json files for the adapter
configuration. The real implementation will need to store the
configuration in the DMR management tree so that it can be maintained by
CLI or the WildFly Web Console.
Questions for further discussion
--------------------------------------------
1. WildFly ships with pre-defined RBAC roles. [3] Should these roles
be available at the realm level or only to the WildFly Web Console?
Could/should other consoles make use of these roles?
2. On first login, you are required to change the admin password. What
other initial setup should be required? Change realm public key?
Change client secret? Others?
3. In the POC, the Keycloak Auth Server WAR is extracted into the
standalone/deployments directory. Are there better options? Should it
even be deployed by default?
4. By default, what Login Options should be enabled for the master
realm? Currently, these options are social login, user registration,
forget password, remember me, verify email, direct grant API, and
require SSL.
5. Should Keycloak audit log be enabled by default? If so, what should
be the expiration value?
6. What should the initial pasword policy be? (length, mixed case,
special chars, etc.)
[1] http://keycloak.jboss.org/
http://docs.jboss.org/keycloak/docs/1.0-beta-1/userguide/html_single/inde...
[2] https://github.com/hal/core
[3]
http://planet.jboss.org/post/role_based_access_control_in_wildfly_8_tech_...
9 years, 10 months
EAR META-INF Visibility
by James R. Perkins
Currently the EAR/META-INF directory is not visible to it's sub-modules.
Should we expose the EAR/META-INF directory to the class path?
I've seen questions a few times when a user wants to use their own copy
of log4j in an EAR and they place the log4j.xxx configuration file in
the EAR/META-INF directory. Since the log4j.jar doesn't have the
directory on it's class path the conflagration file can not be read.
Anyone have thoughts or opinions on this?
--
James R. Perkins
JBoss by Red Hat
9 years, 10 months
Service assumptions and the web profile
by Richard Achmatowicz
Hi
A general question on which services we can assume are available in a
sever configuration and which we cannot.
When installing services, we often need to add in service dependencies.
If a dependency is marked as required and it does not exist, the service
will not start correctly. So, when setting up a service and its
dependencies, if possible, I would like to know which dependencies are
guaranteed to be available and which I may need to optionally check for.
The OPTIONAL flag for dependencies was meant to address this but it now
deprecated as it doesn't work so well when you are unlucky enough to
have your dependency start after your dependent service.
The web profile is intended to be a slimmed down version of the full
profile, and in the case of the EJB subsystem, the spec says that it
need not implement certain EJB feature subsets, among which are
asynchronous method invocations, timer service and remote invocations.
However, our web profile EJB subsystem includes all of these. It is
conceivable that an admin would want to create a slimmed down version of
the EJB subsystem and remove some of these services. All three of these
can be easily removed by deleting configuration elements.
What to do here?
- assume that all subsystems and services defined in the shipped web
profile will be present and no dependency checking is required?
- assume that a certain minimal subset of subsystems and services
defined in the shipped web profile will be present and that an admin may
"turn off" some services, for example the features not part of EJB Lite
and so some form of dependency checking is required? And which services
can we assume are present?
In the case of the EJB subsystem, I would expect that dependencies like
the Remoting system endpoint can be assumed to be present, but the
optional features above and beyond EJB Lite may not be. But this is all
pretty much ad hoc.
Any thoughts?
9 years, 10 months
Hibernate 5 in WildFly 9...
by Scott Marlow
Hi,
Just a heads up for others, that I started making local changes to
integrate the Hibernate ORM master (5.0) branch in Jipijapa and WildFly
master (9.0). If others would like to contribute on this effort, I can
share links to my integration branches.
So far, I have been keeping the 1-1 bidirectional Hibernate dependencies
in mind for this work. Currently, this is done by placing the latest
Hibernate ORM jars in the org.hibernate:main module. Placeholder
modules are also available for earlier Hibernate releases
(org.hibernate:3 + org.hibernate:4.1). When we introduce Hibernate 5 as
the default in WildFly 9, we will also have a legacy org.hibernate:4.3
module.
Applications can also include persistence providers as well, they just
need to include the Jipijapa integration classes as well (see
https://docs.jboss.org/author/display/WFLY8/JPA+Reference+Guide#JPARefere...).
We also could look at doing something similar to Hibernate ORM
org.hibernate.boot.registry.selector.spi.StrategySelector (if we can
find something to group on.) In the past, we talked about adding
logical names for each (future) persistence provider module name, so
that users could use a shorter (logical) name in their application
configuration (e.g. persistence.xml hints).
It would also be awesome to have a configuration setting for specifying
the default persistence provider name based on a logical name that could
be specified in standalone.xml.
Question: Is anyone against removing Hibernate 3.x support from WildFly 9?
Scott
9 years, 10 months
2 instance cluster in master/slave
by Arun Gupta
Trying to following the instructions at:
https://docs.jboss.org/author/display/WFLY8/WildFly+8+Cluster+Howto
This shows how to setup a 2-instance cluster in master/slave where
master is on my laptop and slave is on a Raspi. Couple of questions
...
1). Why the following entry is still referring to 9999 ? Shouldn't it be 9990 ?
<domain-controller>
<remote host="10.211.55.7" port="9999"/>
</domain-controller>
FTR it only works with 9999, not with 9990.
Domain Controller shows the message:
[Host Controller] 15:36:22,811 INFO [org.jboss.as.domain] (Host
Controller Service Threads - 28) JBAS010918: Registered remote slave
host "slave", WildFly 8.1.0.CR2 "Kenny"
2). Master is throwing the following exception:
22:15:25,094 INFO [org.jboss.as.process.Server:server-one.status]
(ProcessController-threads - 3) JBAS012017: Starting process
'Server:server-one'
[Server:server-one] Error occurred during initialization of VM
[Server:server-one] Server VM is only supported on ARMv7+ VFP
22:15:25,557 INFO [org.jboss.as.process.Server:server-one.status]
(reaper for Server:server-one) JBAS012010: Process 'Server:server-one'
finished with an exit status of 1
[Host Controller] 22:15:26,408 INFO [org.jboss.as.host.controller]
(ProcessControllerConnection-thread - 2) JBAS010926: Unregistering
server server-one
[Host Controller] 22:15:26,495 INFO [org.jboss.as.host.controller]
(Controller Boot Thread) JBAS010922: Starting server server-two
22:15:26,417 ERROR [org.jboss.as.process.Server:server-one.status]
(ProcessController-threads - 3) JBAS012006: Failed to send data bytes
to process 'Server:server-one' input stream: java.io.IOException:
Stream closed
at java.lang.ProcessBuilder$NullOutputStream.write(ProcessBuilder.java:434)
[rt.jar:1.7.0_40]
at java.io.OutputStream.write(OutputStream.java:116) [rt.jar:1.7.0_40]
at java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java:82)
[rt.jar:1.7.0_40]
at java.io.BufferedOutputStream.flush(BufferedOutputStream.java:140)
[rt.jar:1.7.0_40]
at java.io.FilterOutputStream.flush(FilterOutputStream.java:140)
[rt.jar:1.7.0_40]
at org.jboss.as.process.stdin.BaseNCodecOutputStream.flush(BaseNCodecOutputStream.java:125)
[wildfly-process-controller-8.1.0.CR2.jar:8.1.0.CR2]
at org.jboss.as.process.stdin.BaseNCodecOutputStream.flush(BaseNCodecOutputStream.java:137)
[wildfly-process-controller-8.1.0.CR2.jar:8.1.0.CR2]
at org.jboss.as.process.stdin.Base64OutputStream.flush(Base64OutputStream.java:44)
[wildfly-process-controller-8.1.0.CR2.jar:8.1.0.CR2]
at org.jboss.as.process.stdin.BaseNCodecOutputStream.close(BaseNCodecOutputStream.java:154)
[wildfly-process-controller-8.1.0.CR2.jar:8.1.0.CR2]
at org.jboss.as.process.stdin.Base64OutputStream.close(Base64OutputStream.java:44)
[wildfly-process-controller-8.1.0.CR2.jar:8.1.0.CR2]
at org.jboss.as.process.ManagedProcess.sendStdin(ManagedProcess.java:164)
[wildfly-process-controller-8.1.0.CR2.jar:8.1.0.CR2]
at org.jboss.as.process.ProcessController.sendStdin(ProcessController.java:207)
[wildfly-process-controller-8.1.0.CR2.jar:8.1.0.CR2]
at org.jboss.as.process.ProcessControllerServerHandler$InitMessageHandler$ConnectedMessageHandler.handleMessage(ProcessControllerServerHandler.java:140)
[wildfly-process-controller-8.1.0.CR2.jar:8.1.0.CR2]
at org.jboss.as.process.protocol.ConnectionImpl.safeHandleMessage(ConnectionImpl.java:269)
[wildfly-process-controller-8.1.0.CR2.jar:8.1.0.CR2]
at org.jboss.as.process.protocol.ConnectionImpl$1$1.run(ConnectionImpl.java:223)
[wildfly-process-controller-8.1.0.CR2.jar:8.1.0.CR2]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
[rt.jar:1.7.0_40]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
[rt.jar:1.7.0_40]
at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_40]
at org.jboss.threads.JBossThread.run(JBossThread.java:122)
[jboss-threads-2.1.1.Final.jar:2.1.1.Final]
22:15:26,573 ERROR [org.jboss.as.protocol.connection]
(ProcessController-threads - 3) JBAS016610: Failed to read a message:
java.io.IOException: Stream closed
at java.lang.ProcessBuilder$NullOutputStream.write(ProcessBuilder.java:434)
[rt.jar:1.7.0_40]
at java.io.OutputStream.write(OutputStream.java:116) [rt.jar:1.7.0_40]
at java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java:82)
[rt.jar:1.7.0_40]
at java.io.BufferedOutputStream.flush(BufferedOutputStream.java:140)
[rt.jar:1.7.0_40]
at java.io.FilterOutputStream.flush(FilterOutputStream.java:140)
[rt.jar:1.7.0_40]
at org.jboss.as.process.stdin.BaseNCodecOutputStream.flush(BaseNCodecOutputStream.java:125)
[wildfly-process-controller-8.1.0.CR2.jar:8.1.0.CR2]
at org.jboss.as.process.stdin.BaseNCodecOutputStream.flush(BaseNCodecOutputStream.java:137)
[wildfly-process-controller-8.1.0.CR2.jar:8.1.0.CR2]
at org.jboss.as.process.stdin.Base64OutputStream.flush(Base64OutputStream.java:44)
[wildfly-process-controller-8.1.0.CR2.jar:8.1.0.CR2]
at org.jboss.as.process.stdin.BaseNCodecOutputStream.close(BaseNCodecOutputStream.java:154)
[wildfly-process-controller-8.1.0.CR2.jar:8.1.0.CR2]
at org.jboss.as.process.stdin.Base64OutputStream.close(Base64OutputStream.java:44)
[wildfly-process-controller-8.1.0.CR2.jar:8.1.0.CR2]
at org.jboss.as.process.ManagedProcess.sendStdin(ManagedProcess.java:164)
[wildfly-process-controller-8.1.0.CR2.jar:8.1.0.CR2]
at org.jboss.as.process.ProcessController.sendStdin(ProcessController.java:207)
[wildfly-process-controller-8.1.0.CR2.jar:8.1.0.CR2]
at org.jboss.as.process.ProcessControllerServerHandler$InitMessageHandler$ConnectedMessageHandler.handleMessage(ProcessControllerServerHandler.java:140)
[wildfly-process-controller-8.1.0.CR2.jar:8.1.0.CR2]
at org.jboss.as.process.protocol.ConnectionImpl.safeHandleMessage(ConnectionImpl.java:269)
[wildfly-process-controller-8.1.0.CR2.jar:8.1.0.CR2]
at org.jboss.as.process.protocol.ConnectionImpl$1$1.run(ConnectionImpl.java:223)
[wildfly-process-controller-8.1.0.CR2.jar:8.1.0.CR2]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
[rt.jar:1.7.0_40]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
[rt.jar:1.7.0_40]
at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_40]
at org.jboss.threads.JBossThread.run(JBossThread.java:122)
[jboss-threads-2.1.1.Final.jar:2.1.1.Final]
Same error for server-two as well.
Trying to explicitly start server-three on slave gives the same error.
This is all using 8.1 CR2.
Any idea what might be wrong ?
Thanks
Aru
--
http://blog.arungupta.me
http://twitter.com/arungupta
9 years, 10 months
Embedded Widfly + Arquillian, just wondering :)
by Paris Apostolopoulos
Hello, greetings from Athens, Greece.
I am wondering if will ever be in the pipeline a full blown widfly-embended (uber jar) version. Why?
Well I have noticed from several teams around, working with JavaE, some of them even coding towards Jboss / Widfly 8, that for some reason, when they wanted to prepare a set of tests to run in embedded mode, then the simplest way was to add 2 dependencies with GlassFish 3.1 jar , setup an Arquillian maven profile and fire it off.
So I am wondering if a fully functional embedded version of Wildfly, 1 dependency away from the widfly adapter and the current ‘fake’ container dependency, wouldn't be a win-win case
for both the use of Arquillian and Wildfly among teams all over the world? One step further, maybe the use of this combo would make some of teams reconsider and ‘start’ adopting more related Jboss / Redhat projects :).
Thanks
------
Paris Apostolopoulos
Senior Software Engineer
'The best thing about a boolean is even if you are wrong, you are only off by a bit'
linkedin | blog | twitter | g+ | podcast |
9 years, 10 months
