How hard would it be to support key based auth by default to make life simpler and more secure ?
by Max Rydahl Andersen
Hi,
Been thinking about the new username/password requirements.
These will make all examples that uses maven deploy plugin, cli scripts, arquillian, jboss tools etc. to somehow
either tell users to type in their username and full password in clear text in pom.xml and other files.
Which sounds worse to me than a default locked down to only localhost…but I'm not a security expert :)
I was wondering how hard it would be to make the authentication support key based auth by default and we make
the tools use ${user.name} and ${user.home}/.jboss/default.pub and .priv (or some other name) for the public/private keys ?
Then the tooling (cli, IDE plugins etc.) could create these by default and examples could use ${user.name} and ${user.home}/.jboss/default.pub as
the preconfigured parameters.
The examples would run out of the box and it would be limited to work from the machine that actually got the right key ( simpler and more secure)
vs to the current AS7.1 master solution where examples won't run out of the box and when configured will run from anywhere - i.e. harder and less secure)
WDYT ?
/max
http://about.me/maxandersen
14 years, 10 months
Defining a jboss-structure.xml file for all SARs
by Thiessen, Todd (Todd)
Is there a way to define a single jboss-structure.xml file to use as a default for all SARs? Currently, it seems I have to define the same jboss-structure.xml file for all SARs. It's a lot of duplication I wish to avoid.
I don't know if this is applicable to jboss7, I am actually trying to do this in Jboss 6, but I can't find a mailing list for 6. If this is the wrong place to ask, I apologize, and if you could direct me to the correct place, that would be very helpful.
14 years, 10 months
Support for port offset on standalone server management sockets
by Brian Stansberry
I've put in a pull request[1] for work that provides $subject[2] along
with some other fixes related to configuring the management interface
sockets. The patch involves xml changes, so I wanted to post on the list
to show the difference and solicit feedback.
The 7.0.x config for these sockets was:
<management-interfaces>
<native-interface address="management" port="9999"
security-realm="ManagementRealm"/>
<http-interface address="management" port="9990" secure-port="12345"
security-realm="ManagementRealm"/>
</management-interfaces>
The intent of the patch is that these management sockets would be
declared in the standalone.xml <socket-binding-group> section along with
all the other sockets. Because of this, the port-offset behavior that
applies to all the other sockets will also apply to these management
socekts.
Then the management-interfaces elements would reference those elements:
<management-interfaces>
<native-interface security-realm="ManagementRealm">
<socket-binding native="management-native"/>
</native-interface>
<http-interface security-realm="ManagementRealm">
<socket-binding http="management-http" https="management-https"/>
</http-interface>
</management-interfaces>
To support writing out legacy configs, the xsd allows a choice between
the above "socket-binding" elements or a "socket" element
<management-interfaces>
<native-interface security-realm="ManagementRealm">
<socket address="management" port="9999"/>
</native-interface>
<http-interface security-realm="ManagementRealm">
<socket address="management-http" port="9990" secure-port="12345"/>
</http-interface>
</management-interfaces>
If configured this way, the socket-binding-group port-offset will not
apply. We allow it in standalone.xml just for backward compatibility.
However, the "address", "port" and "secure-port" attributes support
expressions, so using expressions is another way to prevent port
conflicts when multiple servers run on the same machine.
The other place <management-interfaces> are declared is in host.xml, for
use by the HostController. The socket-binding-group is a server
configuration notion, and isn't part of host.xml. So, for host.xml, only
the 2nd configuration option (with the <socket> element) is allowed.
[1] https://github.com/jbossas/jboss-as/pull/640
[2] https://issues.jboss.org/browse/AS7-1476
--
Brian Stansberry
Principal Software Engineer
JBoss by Red Hat
14 years, 10 months
Continuous Integration Testsuites - Calling AS7
by Darran Lofthouse
Are there any projects out there calling AS7 as part of their own testsuite?
AS7 is about to be secured by default so some minor changes are likely
to be needed to add a user to the AS7 installation and then make the
invocations as that user.
Within the AS7 testsuite we will have examples of the various calls into
the management interfaces with CallbackHandlers and Authenticators
handling this. If you can point me to where you project makes the calls
I can point you to the appropriate example in the AS7 testsuite.
Regards,
Darran Lofthouse.
14 years, 10 months
HTTP API throwing error for jndi-view operation
by Vimal Kansal
Hi,
I am trying to use Http API to display the JNDI view (which I am ble to
get via CLI alright) by pointing my browser as
http://localhost:9990/management/subsystem/naming?operation=jndi-view
and I get the following error :
15:16:53,086 ERROR [stderr] (HttpManagementService-threads - 1)
Exception in thread "HttpManagementService-threads - 1"
java.lang.ExceptionInInitializerError
15:16:53,087 ERROR [stderr] (HttpManagementService-threads - 1)
at
org.jboss.as.domain.http.server.DomainApiHandler.convertGetRequest(DomainApiHandler.java:422)
15:16:53,088 ERROR [stderr] (HttpManagementService-threads - 1)
at
org.jboss.as.domain.http.server.DomainApiHandler.processRequest(DomainApiHandler.java:263)
15:16:53,089 ERROR [stderr] (HttpManagementService-threads - 1)
at
org.jboss.as.domain.http.server.DomainApiHandler.handle(DomainApiHandler.java:191)
15:16:53,091 ERROR [stderr] (HttpManagementService-threads - 1)
at org.jboss.com.sun.net.httpserver.Filter$Chain.doFilter(Filter.java:78)
15:16:53,093 ERROR [stderr] (HttpManagementService-threads - 1)
at org.jboss.sun.net.httpserver.AuthFilter.doFilter(AuthFilter.java:69)
15:16:53,095 ERROR [stderr] (HttpManagementService-threads - 1)
at org.jboss.com.sun.net.httpserver.Filter$Chain.doFilter(Filter.java:81)
15:16:53,096 ERROR [stderr] (HttpManagementService-threads - 1)
at
org.jboss.sun.net.httpserver.ServerImpl$Exchange$LinkHandler.handle(ServerImpl.java:689)
15:16:53,097 ERROR [stderr] (HttpManagementService-threads - 1)
at org.jboss.com.sun.net.httpserver.Filter$Chain.doFilter(Filter.java:78)
15:16:53,098 ERROR [stderr] (HttpManagementService-threads - 1)
at org.jboss.sun.net.httpserver.ServerImpl$Exchange.run(ServerImpl.java:661)
15:16:53,099 ERROR [stderr] (HttpManagementService-threads - 1)
at
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
15:16:53,100 ERROR [stderr] (HttpManagementService-threads - 1)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
15:16:53,101 ERROR [stderr] (HttpManagementService-threads - 1)
at java.lang.Thread.run(Thread.java:662)
15:16:53,102 ERROR [stderr] (HttpManagementService-threads - 1)
at org.jboss.threads.JBossThread.run(JBossThread.java:122)
15:16:53,103 ERROR [stderr] (HttpManagementService-threads - 1) Caused
by: java.lang.IllegalArgumentException: Invalid bundle interface
org.jboss.as.domain.http.server.HttpServerMessages (implementati
on not found)
15:16:53,103 ERROR [stderr] (HttpManagementService-threads - 1)
at org.jboss.logging.Messages.getBundle(Messages.java:81)
15:16:53,104 ERROR [stderr] (HttpManagementService-threads - 1)
at org.jboss.logging.Messages.getBundle(Messages.java:46)
15:16:53,105 ERROR [stderr] (HttpManagementService-threads - 1)
at
org.jboss.as.domain.http.server.HttpServerMessages.<clinit>(HttpServerMessages.java:39)
15:16:53,106 ERROR [stderr] (HttpManagementService-threads - 1)
... 13 more
Thx
Vimal
14 years, 10 months
Fwd: Questions about the console for Socket Binding Groups
by Heiko Braun
David, I am forwarding your questions to the dev list.
@Brian: Some questions for you inline...
Begin forwarded message:
> 1) Can the user create a new Socket Binding Group in a standalone instance or in a domain? I can create new individual socket bindings, but the drop-down menu for the binding group in teh console shows only the main default group, and I can't see an "Add new socket binding group" button or interface.
not yet. I haven't actually thought about this.
Brian, is it supported at all?
>
> 2) Will the standalone instance be able to use multiple socket binding groups at all? I tried to create extra <socket-binding-groups> like in the domain configuration XML but the inclusion of additional groups seem to breaks the server at runtime. Perhaps I'm doing something wrong.
>
Please create a Jira with the configuration attached.
> 3) Are socket binding groups only for domain instances? I assumed a developer could create multiple groups (in the XML, CLI or via console) to have different presets for different development tests or projects (which seems useful). Is this the intention?
Brian?
14 years, 10 months
issues with the management protocol
by Emanuel Muckenhuber
I was investing some hangs with the domain Heiko was seeing using the
console: https://issues.jboss.org/browse/AS7-2535
This turned out to be a problem how transactional requests with the
proxy controllers are handled.
Basically what happens is when a request is executed on a remote
controller, the message handler blocks until the operation is 'done' and
the preparedResult was sent back to the proxyStepHandler, which then
either tells the remote controller to keep or rollback the changes.
The issue with this is that the message handler is blocking using the
remote endpoint thread pool, meaning that if you have enough mgmt
requests they end up blocking the endpoint completely and none of those
operations can complete.
I just moved that into the client side (since this one is waiting
anyway), which should solve the issue:
https://github.com/emuckenhuber/jboss-as/commit/f5e2d6b80f9199e408641e6a0...
Since there seem to be other people looking into issues with the mgmt
protocol as well - any thoughts?
Thanks,
Emanuel
14 years, 10 months
