Java secure development part 3

490 | P a g e
<name>invocation</name>
<type>org.jboss.invocation.Invocation</type>
</parameter>
<return-type>java.lang.Object</return-type>

<descriptors>
<interceptors>
<interceptor code="org.jboss.jmx.connector.invoker.AuthenticationInterceptor"
securityDomain="java:/jaas/jmx-console"></interceptor>
</interceptors>
</descriptors>
</operation>
The value of the securityDomain attribute maps to the security domain name found in the
conf/login-config.xml definitions the same way as the jboss.xml, jboss-web.xml security-domain
elements do. In this case the jmx-console security domain configuration is being used.
Note, in some version of jboss when running under java5+, you may see an error like the
following:
. This is due to a change in how the jmx descriptor names are stored with case preserved. To
work around this isssue simply use all lower case attribute names:
...
<descriptors>
<interceptors>
securitydomain="java:/jaas/jmx-console"></interceptor>
</interceptors>
</descriptors>
This still works under jdk14.
Enabling authorization to the RMIAdaptor service
Along the lines of the AuthenticationInterceptor, an AuthorizationInterceptor is available in
JBoss. The interceptor should be placed after the AuthenticationInterceptor and has the
following configuration.
 authorizingClass : Fully Qualified Name of a class that does the authorization and which
contains a method with the following signature
"public void authorize( Principal caller, Subject subject, String objectname,String
opname)" that can throw a java.lang.SecurityException
An example of an authorizing class is available in JBoss. It is
theorg.jboss.jmx.connector.invoker.RolesAuthorization, which looks for an hardcoded
"JBossAdmin" role in the authenticated subject.
<descriptors>
<interceptors>

491 | P a g e
<interceptor code="org.jboss.jmx.connector.invoker.AuthorizationInterceptor"
authorizingClass="org.jboss.jmx.connector.invoker.RolesAuthorization"></interceptor>
</interceptors>
</descriptors>
Starting 4.0.4.GA, we have an authorization delegate that looks for passwords from a
properties file called as
"jmxinvoker-roles.properties" either in a jar file or can be in the conf directory.
As before,
<descriptors>
<interceptors>
<interceptor code="org.jboss.jmx.connector.invoker.AuthorizationInterceptor"
authorizingClass="org.jboss.jmx.connector.invoker.ExternalizableRolesAuthorization"></interc
eptor>
</interceptors>
</descriptors>
The format of the jmxinvoker-roles.properties file is as follows:
#Specify the roles that are authorized to access the jmx invoker delimited by comma
roles=testRole,testRole1
If you don't succeed in securing the RMIInvoker (that is, calls are made without forcing a login),
try placing the security-service.xml in a SAR.
Create a folder named security.sar that has a subfolder named META-INF. Then move your
security-service.xml to this folder and rename it to jboss-service.xml. Place the security.sar in
you deploy-folder.
The RMI Class Loading Service
There is a simple http service that supports requests for classes for RMI dynamic class loading,
org.jboss.web.WebService. The configurable attributes for the WebService MBean service are as
follows:
 Port: the WebService listening port number. A port of 0 will use any available port.
 Host: Set the name of the public interface to use for the host portion of the RMI
codebase URL.

492 | P a g e
 BindAddress: the specific address the WebService listens on. This can be used on a
multi-homed host for a java.net.ServerSocket that will only accept connect requests to
one of its addresses.
 Backlog: The maximum queue length for incoming connection indications (a request to
connect) is set to the backlog parameter. If a connection indication arrives when the
queue is full, the connection is refused.
 DownloadServerClasses: A flag indicating if the server should attempt to download
classes from the thread context class loader when a request arrives that does not have a
class loader key prefix.
 DownloadResources (4.0.3+) : A flag indicating if the server should attempt to download
non .class file resources using the from thread context class loader. Note that this is
generally a security risk as it allows access to server configuration files which may
contain security settings.
 ThreadPool (4.0.2+): The org.jboss.util.threadpool.BasicThreadPoolMBean instance
thread pool used for the WebServer class loading. Typically this is used with the mbean
service dependency injection syntax as shown in the example configuration.
An example mbean service descriptor fragment is:
<mbean code="org.jboss.web.WebService"
name="jboss:service=WebService">
<attribute name="Port">8083</attribute>

<attribute name="DownloadServerClasses">true</attribute>

<attribute name="DownloadResources">false</attribute>
<attribute name="Host">${jboss.bind.address}</attribute>
<attribute name="BindAddress">${jboss.bind.address}</attribute>

<depends optional-attribute-name="ThreadPool"
proxy-type="attribute">jboss.system:service=ThreadPool</depends>
</mbean>
If the MBean is created, it calculates an URL based on the Host and Port attribute. (If no Host
atribute was given it tries to use the java.rmi.server.name system property or the local
hostname otherwise. This calculated URL will be stored into the java.rmi.server.codebase
attribute. (One user of this attribute is for example the exported JNDI server stub).
Securing the RMI Dynamic ClassLoading Service
The DownloadResources setting should certainy be false if you have any concern about leaking
information through this server. Beyond that, one step in increasing the security is to set

493 | P a g e
DownloadServerClasses to false so that only ejb deployment classes are available for download.
Another is to use an anonymous port so that access is not via a well know port as a security by
obscurity measure.
Removing the RMI Dynamic ClassLoading Service
Removal of the WebService altogether is certainly the best security step if you want to limit
access points. You need to remove the mbean definition from jboss-server.xml and also remove
the dependency of the EJB Deployer:

<mbean code="org.jboss.ejb.EJBDeployer" name="jboss.ejb:service=EJBDeployer">
...

</mbean>
Secure Using a Tomcat (or another webserver) for dynamic classloading
You can take complete control of what resources/classes are available for dynamic class loading
by deploying only the classes you want to expose for dynamic classloading in a war file, e.g.
remoteclasses.war to a standalone tomcat or webserver. You then tell RMI to use this address
as the codebase for dynamic classloading when starting JBoss, e.g.
./run.sh -Djava.rmi.server.codebase=http://hostname:8080/remoteclasses
You should of cause also remove the WebService MBean as described above.
JBossMQ Security Configuration
To configure security on JBoss MQ there are a few steps you need to take. These involve the
following:
 Identify a security domain to use for messaging.
 Configure your MDB:s to use security credentials when reading from the message
queues / topics.
 Use the authenticated connection methods when connecting to the messaging service
from your clients.
 Configure security on the topics and queues.
Identify a security domain

494 | P a g e
Security domains are configured in the conf/login-config.xml file. The sample file that comes
with the distribution is pretty well commented with examples. By default there is a security
domain configured with the name "jbossmq".
To tell JBoss MQ which security domain to use when checking credentials, edit the
filedeploy/jms/jbossmq-service.xml. In this file you will have an entry that looks something like
this:
<mbean code="org.jboss.mq.security.SecurityManager" name="jboss.mq:service=SecurityManager">
<attribute name="DefaultSecurityConfig">
<security>
<role name="guest" read="true" write="true" create="true"></role>
</security>
</attribute>
<attribute name="SecurityDomain">java:/jaas/jbossmq</attribute>
<depends optional-attribute-name="NextInterceptor">jboss.mq:service=DestinationManager</depends>
</mbean>
To change security domain to use, change the attribute called "SecurityDomain".
Notice the DefaultSecurityConfig. To enable non-authenticated messaging make sure that the
role name, in this case "guest" is the same as the "unauthenticatedIdentity" in the definition of
the security domain in login-config.xml.
Configure MDB:s to use security
Your message driven beans "log in" to the queues / topics that "drive" them. If you enable
security in JMS the beans will have to identify themselves.
What identity the should use you specify in the jboss.xml file for the given beans. See below
example:
<message-driven>
<ejb-name>CMyMessageBean</ejb-name>
<destination-jndi-name>queue/myQueue</destination-jndi-name>
<mdb-user>scott</mdb-user>
<mdb-passwd>tiger</mdb-passwd>
<resource-ref>
<res-ref-name>jdbc/base</res-ref-name>
<jndi-name>java:/jdbc/myconnection</jndi-name>
</resource-ref>
</message-driven>

495 | P a g e
The mdb-user and mdb-passwd should match a user that exists in your security domain.
Use authenticated connections in client code
If you have clients connecting to your security enabled messaging service they will have to
supply user credentials. It is not enough to login using the client-login you normally use when
calling JBoss EJB:s, in fact it's not even related, so you don't have to login using that client-login.
What you have to do is use these methods when creating the jms-connections:
QueueConnectionFactory connectionFactory =
(QueueConnectionFactory) ctx.lookup("ConnectionFactory");
try {
destination =
(javax.jms.Queue) ctx.lookup(QUEUENAME);
} catch (javax.naming.NameNotFoundException nne) {
m_log.fatal("Could not find recipent queue: " + QUEUENAME);
System.exit(1);
}
QueueConnection connection = connectionFactory.createQueueConnection(JMSUSER, JMSPASS);
And for topics:
TopicConnectionFactory connectionFactory =
(TopicConnectionFactory) ctx.lookup("ConnectionFactory");
try {
destination =
(javax.jms.Topic) ctx.lookup(TOPICNAME);
} catch (javax.naming.NameNotFoundException nne) {
m_log.fatal("Could not find topic: " + TOPICNAME);
System.exit(1);
}
TopicConnection connection = connectionFactory.createTopicConnection(JMSUSER, JMSPASS);
Configure security on the topics and queues
In the deploy/jms/jbossmq-destinations-service.xml file you can configure the topics, queues
and who can access them and how. The default file that comes with JBoss contains comments
and examples that describes how this step is done.
Make sure that the user that you supplied in your jboss.xml file for your MDB:s match the roles
that you specify here.
Disable Security

496 | P a g e
As of JBoss 4.2.3, edit server/xxx/deploy/jms/jbossmq-service.xml. Find
<mbean code="org.jboss.mq.server.jmx.Invoker" name="jboss.mq:service=Invoker">
And change 2 lines down from:
<depends optional-attribute-name="NextInterceptor">jboss.mq:service=SecurityManager</depends>
To:
<depends optional-attribute-name="NextInterceptor">jboss.mq:service=TracingInterceptor</depends>
This will eliminate principal=null errors for unauthenticated Message Driven Bean (MDB) by
removing the SecurityManager interceptor that checks for them. The errors look like this:
javax.jms.JMSSecurityException: User: null is NOT authenticated
at org.jboss.mq.security.SecurityManager.authenticate(SecurityManager.java:230)
at org.jboss.mq.security.ServerSecurityInterceptor.authenticate(ServerSecurityInterceptor.java:66)
at org.jboss.mq.server.TracingInterceptor.authenticate(TracingInterceptor.java:613)
at org.jboss.mq.server.JMSServerInvoker.authenticate(JMSServerInvoker.java:172)
at org.jboss.mq.il.jvm.JVMServerIL.authenticate(JVMServerIL.java:165)
at org.jboss.mq.Connection.authenticate(Connection.java:1067)
...
13:54:17,255 INFO [JMSContainerInvoker] Waiting for reconnect internal 10000ms for
RandomClientMessageBean
13:54:27,256 INFO [JMSContainerInvoker] Trying to reconnect to JMS provider for
13:54:27,257 ERROR [UsersRolesLoginModule] Failed to load users/passwords/role files
java.io.IOException: No properties file: props/jbossmq-users.properties or defaults: defaultUsers.properties
found
13:56:18,725 INFO [JMSContainerInvoker] Waiting for reconnect internal 10000ms for
..
2008-12-28 13:53:42,806 DEBUG [org.jboss.ejb.plugins.jms.DLQHandler] Initialization failed DLQHandler
Removing HSQLDB
JBoss 3.2 and 4.0.x
 remove the descriptor for the HSQLDB datasource DefaultDS by deleting deploy/hsqldb-
ds.xml;
 in conf/login-config.xml, comment out the <application-policy> declaration with the
name"HsqlDbRealm";
 remove the HSQLDB libraries by deleting lib/hsqldb.jar and lib/hsqldb-plugin.jar.
 Several services rely on the datasource:

497 | P a g e
o JBossMQ;
o EJBTimerService;
o HiLoGenerator.
 After removing the datasource you should either:
o configure another datasource with the JNDI name DefaultDS;
o go through all the references in the various descriptors and change them to
reference another datasource.
JBoss AS 5.x.x
Remove the libraries hsqldb.jar and hsqldb-plugin.jar from jboss/common/lib/.
Copy the necessary driver libraries for the new dbms to the directory jboss/server/xxx/lib/.
Create a database and users with enough rights for this database.
Modify the application-policy HsqlDbRealm in jboss/server/xxx/conf/login-config.xml. Configure
the username and password for the database. Rename it. For example MySqlDbRealm.
Remove the data source jboss/server/xxx/deploy/hsqldb-ds.xml which has DefaultDS as jndi
name and create a new local-tx data source with DefaultDS as jndi name in directory
jboss/server/xxx/deploy/. Examples could be found in jboss/docs/examples/jca/.
Add to the new data source <transaction-
isolation>TRANSACTION_READ_COMMITTED</transaction-isolation> and add the <security-
domain>xxxDbRealm</security-domain> which you defined in jboss/server/xxx/conf/login-
config.xml
Modify jboss/server/xxx/conf/standardjbosscmp-jdbc.xml so that the <datasource-mapping>
has the correct mapping and set <fk-constraint> on true, if your db could handle foreign keys
 Remove jboss/server/xxx/deploy/messaging/hsqldb-persistence-service.xml and create
a new xxx-persistence-service.xml. Examples could be found in
jboss/docs/examples/jms/.
Make sure that <depends optional-attribute-
name="ChannelFactoryName">jboss.jgroups:service=ChannelFactory</depends> is
replaced by <attribute
name="ChannelFactoryName">jboss.jgroups:service=ChannelFactory</attribute> (see
jiraJBAS-6333 and JBAS-6991)
Configuring JBoss for use Behind a Firewall
JBoss comes with many socket based services that open listening ports. In this section we list the
services
that open ports that might need to be configured to work when accessing JBoss behind a
firewall. The following table, shows the ports, socket type, associated service and link to the
service configuration for the services in the default configuration file set.
Port Type Service Descriptor Service Name
Attribute
Name
1098 TCP conf/jboss-service.xml jboss:service=Naming RmiPort
1099 TCP conf/jboss-service.xml jboss:service=Naming Port

498 | P a g e
3873 TCP
deploy/ejb3.deployer/ME
TA-INF/jboss-service.xml
jboss.remoting:type=Connector,name=DefaultEjb3Connector,handler=ejb
3
InvokerLocator
4444 TCP conf/jboss-service.xml jboss:service=invoker,type=jrmp (legacy 4.0.x invoker) RMIObjectPort
4445 TCP conf/jboss-service.xml jboss:service=invoker,type=pooled (legacy 4.0.x invoker) ServerBindPort
4446 TCP conf/jboss-service.xml
jboss.remoting:service=Connector,transport=socket (EJB2 beans in AS/EAP
4.2+)
serverBindPort
on
Configuration
8009 TCP
deploy/jbossweb-
tomcat41.sar/META-
INF/jboss-service.xml
jboss.web:service=WebServer
port on AJP
Connector
8080 TCP
deploy/jbossweb-
tomcat41.sar/META-
jboss.web:service=WebServer
port on HTTP
Connector
8083 TCP conf/jboss-service.xml jboss:service=WebService Port
8090 TCP
deploy/jms/oil-
service.xml
jboss.mq:service=InvocationLayer,type=OIL ServerBindPort
8092 TCP
deploy/jms/oil2-
service.xml
jboss.mq:service=InvocationLayer,type=OIL2 ServerBindPort
8093 TCP
deploy/jms/uil2-
service.xml
jboss.mq:service=InvocationLayer,type=UIL2 ServerBindPort
0(a) TCP
deploy/jms/rmi-il-
service.xml
jboss.mq:service=InvocationLayer,type=RMI NONE
0(b) UDP
deploy/snmp-
adaptor.sar/META-
jboss.jmx:name=SnmpAgent,service=snmp,type=adaptor NONE
(a) This service binds to an anonymous TCP port and does not support configuration of the port
or bind interface. Remove the rmi-il-service.xml to disable it NOTE: this RMI invoker service is
deprecated since the beginning of 2005
(b) This service binds to an anonymous UDP port and does not support configuration of the port
or bind interface. Remove the snmp-adaptor.sar to disable it
JBossMessaging will use these ports:
Port Type Service Descriptor Service Name Attribute Name
4457 TCP
deploy/jboss-
messaging.sar/remoting-
bisocket-service.xml
jboss.messaging:service=Connector,transport=bisocket serverBindPort
Random
by
default
TCP
deploy/jboss-
jboss.messaging:service=Connector,transport=bisocket secondaryBindPort
Random
by
default
TCP
deploy/jboss-
jboss.messaging:service=Connector,transport=bisocket secondaryConnectPort
 Case you are using JBossMessaging in your configuration, you won't have any
deploy/jms ports being used as described on the first table
Additional ports found in the all configuration:
Port Type Service Descriptor Service Name Attribute Name
1100 TCP deploy/cluster-service.xml jboss:service=HAJNDI Port
1101 TCP deploy/cluster-service.xml jboss:service=HAJNDI RmiPort

499 | P a g e
1102 UDP deploy/cluster-service.xml jboss:service=HAJNDI AutoDiscoveryGroup
1161 UDP
deploy/snmp-
adaptor.sar/META-
jboss.jmx:name=SnmpAgent,service=snmp,type=adaptor Port
1162 UDP
deploy/snmp-
adaptor.sar/META-
jboss.jmx:name=SnmpAgent,service=trapd,type=logger Port
3528 TCP conf/jacorb.properties OAPort
4447 TCP deploy/cluster-service.xml jboss:service=invoker,type=jrmpha (legacy 4.0.x invoker) RMIObjectPort
4448 TCP deploy/cluster-service.xml
jboss:service=invoker,type=pooledha (legacy 4.0.x
invoker)
ServerBindPort
49152 TCP deploy/cluster-service.xml jboss:service=${jboss.partition.name:DefaultPartition}
start_port on
FD_SOCK
49153 TCP
deploy/tc5-
cluster.sar/META-INF/jboss-
service.xml
jboss.cache:service=TomcatClusteringCache
start_port on
FD_SOCK
One possible configuration for RMI through a firewall
NOTE: this was only tested in version 3.2.5 with java 1.4, but information in the forums indicate
that this method has worked for several years. Search for NAT to find related information.
Open three ports through your firewall, one for the naming service, a second for the naming
service RmiPort, and a third for the jrmp RMIObjectPort. These ports must be "fixed" on the
system behind the firewall so that communications always happen on ports opened through the
firewall. This is done in the jboss-service.xml file.
<mbean code="org.jboss.naming.NamingService"
name="jboss:service=Naming">

<attribute name="Port">1099</attribute>
<attribute name="RmiPort">1098</attribute>
</mbean>
and

<mbean code="org.jboss.invocation.jrmp.server.JRMPInvoker"
name="jboss:service=invoker,type=jrmp">
<attribute name="RMIObjectPort">4444</attribute>
<!--
<attribute name="ServerAddress">${jboss.bind.address}</attribute>
<attribute name="RMIClientSocketFactory">custom</attribute>
<attribute name="RMIServerSocketFactory">custom</attribute>
<attribute name="SecurityDomain">ssl-domain-name</attribute>

500 | P a g e
-->
<depends>jboss:service=TransactionManager</depends>
</mbean>
Then, on the system behind the firewall, the following parameters need to be added to the java
command line in the run.sh script to pass back the "correct" RMI information to the system
outside of the firewall. "Correct" in this case means the hostname that the outside system
refers to when addressing the systembehind the firewall.
-Djava.rmi.server.hostname=<external_host_name>
-Djava.rmi.server.useLocalHostname=true
NOTE: shouldn't it be -Djava.rmi.server.useLocalHostname=false since it should NOT return the
local host name? Works here (4.2.2.GA) with set to false.
This solves the problem of the machine behind the firewall passing back it's local IP address that
the machine outside the firewall cannot get to. NOTE: this assumes a pretty simple setup where
everything outside the firewall references the machine behind the firewall with the same host
name.
In more complex configurations, it may be necessicary for the system running behind the
firewall to be able to resolve
:1099" when the initial context is created for the RMI access.
PooledInvoker
When using the PooledInvoker the attribute "ClientConnectAddress"(jboss-service.xml) is the
host name that clients will use to connect to the server. You might need to set this to a DNS
name that can be resolved by remote clients. This will default to the hostname of the server
running jboss which may not be accessible by remote clients.
To invoke services behin firewall or NAT you need to modify two file
jboss/server/default/deploy/ejb3.deployer/META-INF/jboss-service.xml
<mbean code="org.jboss.remoting.transport.Connector"
name="jboss.remoting:type=Connector,name=DefaultEjb3Connector,handler=ejb3">
<depends>jboss.aop:service=AspectDeployer</depends>
<attribute name="Configuration">
<config>
<invoker transport="socket">
<attribute name="numAcceptThreads">1</attribute>
<attribute name="maxPoolSize">300</attribute>
<attribute name="clientMaxPoolSize" isParam="true">50</attribute>

501 | P a g e
<attribute name="timeout" isParam="true">60000</attribute>
<attribute name="serverBindAddress">${jboss.bind.address}</attribute>
<attribute name="serverBindPort">3873</attribute>

<attribute name="clientConnectAddress">webaddress.com</attribute>
<attribute name="clientConnectPort">3873</attribute>
<attribute name="backlog">200</attribute>
</invoker>
<handlers>
<handler subsystem="AOP">org.jboss.aspects.remoting.AOPRemotingInvocationHandler</handler>
</handlers>
</config>
</attribute>
</mbean>
and
/jboss/server/default/deploy/http-invoker.sar/META-INF/jboss-services.xml

<mbean code="org.jboss.invocation.http.server.HttpInvoker"
name="jboss:service=invoker,type=https">

<attribute name="InvokerURL">https://webaddress.com:8443/invoker/EJBInvokerServlet</attribute>
<attribute name="InvokerURLPrefix">https://</attribute>
<attribute name="InvokerURLSuffix">:8443/invoker/EJBInvokerServlet</attribute>

<attribute name="UseHostName">false</attribute>
</mbean>

<mbean code="org.jboss.invocation.http.server.HttpProxyFactory"
name="jboss:service=invoker,type=https,target=Naming">

<attribute name="InvokerName">jboss:service=Naming</attribute>

<attribute name="InvokerURL">https://webaddress.com:8443/invoker/JMXInvokerServlet</attribute>
<attribute name="InvokerURLPrefix">https://</attribute>
<attribute name="InvokerURLSuffix">:8443/invoker/JMXInvokerServlet
</attribute>
<attribute name="UseHostName">false</attribute>
<attribute name="ExportedInterface">org.jnp.interfaces.Naming
</attribute>
<attribute name="JndiName"></attribute>
<attribute name="ClientInterceptors">
<interceptors>
<interceptor>org.jboss.proxy.ClientMethodInterceptor

502 | P a g e
</interceptor>
<interceptor>org.jboss.proxy.SecurityInterceptor
</interceptor>
<interceptor>org.jboss.naming.interceptors.ExceptionInterceptor
</interceptor>
<interceptor>org.jboss.invocation.InvokerInterceptor
</interceptor>
</interceptors>
</attribute>
</mbean>
Using mod_proxy with JBoss bundle and Apache2.2.x
This following information outlines the various steps required to install a basic load-balancing
solution based on mod_proxy, mod_proxy_balancer and JBoss. Mod_proxy allows to use
http/https and AJP protocols to proxy to JBoss. This documentation is for Apache httpd-2.2.x if
you have to use older version of httpd see Load Balancing using mod_rewrite and mod_proxy
Using mod_proxy with http/https:
Step 1: Download Apache2.2.x Web Server
Get the latest Apache2.2.x package from Apache.org and install it. We require no special
configuration, just use the default settings. In the following steps, APACHE_HOME will represent
the Apache install directory.
+
 Note:* At the time of the writting of this document Apache 2.2.9 is most stable version of
Apache httpd-2.2.x and is recommended if you want to use load-balancing using mod_proxy
+
Step 2: Setup Apache to use mod_proxy (HTTP)
Make sure that at least following modules are loaded (uncomment this in httpd.conf)
LoadModule proxy_module modules/mod_proxy.so
LoadModule proxy_balancer_module modules/mod_proxy_balancer.so
LoadModule proxy_http_module modules/mod_proxy_http.so
These are sufficient for http load balancing. However you may need to load mod_proxy_ftp
module if you are using ftp or load mod_proxy_connect module if you are using SSL

503 | P a g e
Add those lines in APACHE_HOME/conf/httpd.conf :
<Proxy balancer://mycluster>
Order deny,allow
Allow from all
BalancerMember http://host1:8080 route=node1
BalancerMember http://host2:8180 route=node2
</Proxy>
ProxyPass /jmx-console balancer://mycluster
ProxyPassReverse /jmx-console http://host1:8080/jmx-console
ProxyPassReverse /jmx-console http://host2:8180/jmx-console
By default the requests are load balanced in byrequests fashion, which performs weighted
request counting. This is determined by parameter lbmethod. The stickysession parameter is
also required, as there is no default value. stickysession is used to determine which URL session
name or cookie to use when looking for the route for the request.
ProxyPass /jmx-console balancer://mycluster lbmethod=byrequests stickysession=JSESSIONID|jsessionid
You can find more about ProxyPass attributes in the Apache HTTP Server documentation at
http://httpd.apache.org/docs/2.2/mod/mod_proxy.html
Step 3: Configure JBoss Web if you want to use sticky session
Edit JBOSS_HOME/server/all/deploy/jbossweb-web.deployer/server.xml (replace /all with your
own server name)
Locate the <Engine> element and add an attribute for jvmRoute:
<Engine name="jboss.web" defaultHost="localhost" jvmRoute="node1">
.
</Engine>
Step 4: Configure JBoss session to add jvmRoute to the sessions
Finally, we need to tell JBoss Web to add the jvmRoute value to its session cookies so that
mod_proxy_balancer can route incoming requests.

504 | P a g e
Edit JBOSS_HOME/server/all/deploy/jboss-web.deployer/META-INF/jboss-service.xml (replace
/all with your own server name)
Locate the attribute element with a name of UseJK, and set its value to "true":
<attribute name="UseJK">true</attribute>
Using mod_proxy with AJP:
Step 1: See Using mod_proxy with http/https (above)
Step 2: Setup Apache to use mod_proxy (AJP)
Make sure that at least following modules are loaded (uncomment this in httpd.conf)
LoadModule proxy_module modules/mod_proxy.so
LoadModule proxy_balancer_module modules/mod_proxy_balancer.so
LoadModule proxy_ajp_module modules/mod_proxy_ajp.so
Add those lines in APACHE_HOME/conf/httpd.conf :
<Proxy balancer://mycluster>
Order deny,allow
Allow from all
BalancerMember ajp://localhost:8009/jmx-console
BalancerMember ajp://localhost:8109/jmx-console
</Proxy>
ProxyPass /jmx-console balancer://mycluster
When to use mod_jk and when to use mod_proxy for load-balancing
 Load balancing is definitely easier to configure using mod_proxy as compared to mod_jk1.x.

505 | P a g e
 mod_proxy works well since version 2.2.2 of Apache httpd. Don't use mod_proxy with older
version of Apache httpd.
 mod_jk is in continous development phase and is tried and tested by many people arround the
world. mod_proxy is fairly new.
 mod_proxy_http doesn't forward the SSL information to JBoss Web (See Forwarding SSL
environment when using http/https proxy )
 mod_proxy allows to use https between Apache httpd and JBoss Web (See Encrypting
connection between httpd and TC).
If you decide to use mod_proxy, you have two options for load-balancing
When to use mod_proxy + mod_proxy_http and mod_proxy +
mod_proxy_ajp for load-balancing
 AJP is binary, so there was the transmission savings
 JBoss Web could handle AJP faster and more efficiently than HTTP (the AJP endpoints were
quicker than the HTTP endpoint implementations)
 However mod_proxy_http now implements connection pooling and load balancing so one needs
to test mod_proxy_http as well as mod_proxy_ajp before deciding
Here is the FAQ on mod_proxy_ajp vs mod_jk
Using sticky sessions:
Add stickysession parameter to ProxyPass
ProxyPass /jmx-console balancer://mycluster stickysession=JSESSIONID lbmethod=bytraffic
nofailover=Off
Sticky Session is supported by mod_proxy_http as well as mod_proxy_ajp
 Note:* If you are using mod_proxy_http you have to create one ProxyPassReverse for each BalancerMember you
define in the balancer.
Going over the 8K AJP headers limits:
The default size of a AJP package is 8K as the http headers are sent only in the first packet it
could be needed to overcome the limit.
To reach this you need to add packetSize parameter in the <Connector/> parameter like:

506 | P a g e
<Connector port="8009" protocol="AJP/1.3"
packetSize="20000"
redirectPort="8443" ></Connector>
and ProxyIOBufferSize (also LimitRequestFieldsize probably) directive in httpd.conf too. For
example:
ProxyIOBufferSize 19000
LimitRequestFieldsize 18000
packetSize is supported since Tomcat 5.5.21 and Tomcat 6.0.1.
Old version of httpd-2.2.x (x<5) need a patch to support this extension. You find the patch
athttp://people.apache.org/~jfclere/patches/ProxyIOBufferSize.patch
Set Up A Keystore
Generate keystore file with your own password
 quick setup
$ keytool -genkey -keystore /data01/jboss/server/xxx/conf/keystore -alias jbossAdmin
$ keytool -list -keystore /data01/jboss/server/xxx/conf/keystore
SSLSetup
Tomcat configurations
JBoss-3.2.3/Tomcat-4.1.x
 Create a test keystore in the server/default/conf directory:
starksm@banshee9100 conf$ keytool -genkey -alias tc-ssl -keyalg RSA -keystore server.keystore -validity
3650
Enter keystore password: tc-ssl
What is your first and last name?
[Unknown]: www.myhost.com
What is the name of your organizational unit?
[Unknown]: Some dot com
What is the name of your organization?
[Unknown]: Security
What is the name of your City or Locality?
[Unknown]: SomeCity
What is the name of your State or Province?
[Unknown]: Washington

507 | P a g e
What is the two-letter country code for this unit?
[Unknown]: US
Is CN=www.myhost.com, OU=Some dot com, O=Security, L=SomeCity, ST=Washington, C=US correct?
[no]: yes
Enter key password for <tc-ssl>
(RETURN if same as keystore password):
 Please note that the answer to the "first and last name?" question is important. This answer
consitutes the CN= part of your so called distinguished name. The browser will check that the
CN= part matches the end of the domain it requested the web page from. If the CN= and the the
web page domain do not match the browser will display an additional warning. So for local
development you may want to use "localhost" as CN and later on use the domain name of the
host that will serve request from the internet.
 Edit jbossweb-tomcat41.sar/META-INF/jboss-service.xml and uncomment the following section
and update the keystoreFile,

<Connector className = "org.apache.coyote.tomcat4.CoyoteConnector"
address="${jboss.bind.address}" port = "8443" scheme = "https"
secure = "true">
<Factory className = "org.apache.coyote.tomcat4.CoyoteServerSocketFactory"
keystoreFile="${jboss.server.home.dir}/conf/server.keystore"
keystorePass="tc-ssl"
protocol = "TLS"></Factory>
</Connector>
 You need to replace the value for keystorePass with the password you used while creating the
key.
 Start the server and browse to: https://localhost:8443/jmx-console/index.jsp to test the ssl
connection. Your browser should complain about an not trusting the signer. To avoid this you
would need to either import the server certificate into you browser or obtain a certificate from a
well known cert authority (Ex: Thawte, Verisign). See the examples section of the keytool
docs:http://java.sun.com/j2se/1.4.2/docs/tooldocs/windows/keytool.html for the proceedure
to create a server certificate that has been signed by a trusted CA.
On startup the log may contain this warning:
10:31:48,952 DEBUG [SSLImplementation] [getInstance.119] Error loading SSL Implementation
org.apache.tomcat.util.net.puretls.PureTLSImplementation
java.lang.ClassNotFoundException: No ClassLoaders found for:
org.apache.tomcat.util.net.puretls.PureTLSImplementation
Ignore it unless you are tyring to use the PureTLS SSL implementation. Tomcat tries to find
different SSL implementations and defaults to JSSE if no others are found.

508 | P a g e
JBoss-3.2.4+/Tomcat-5.0.x
In jboss-3.2.4+ the tomcat-5.0.x container has its configuration in the jbossweb-
tomcat50.sar/server.xml descriptor.
JBoss-4.2.1
In jboss-4.2.1 the web container has its configuration in the deploy/jboss-
web.deployer/server.xml descriptor.
JBoss-5 and later
In JBoss 5 and later, the web deployer is configured from deploy/jbossweb.sar/server.xml.
Using a trusted certificate obtained from a well known CA
You may get the certificate in a format not appropriate for using it directly in JBoss/Tomcat. You
may use the openssl tool to convert the certifcate and key in a suitable format:
openssl pkcs12 -export -out server.keystore -in certificate.pem -inkey private.key
If you get an error like this
10300:error:0D0680A8:asn1 encoding routines:ASN1_CHECK_TLEN:wrong tag:tasn_dec.c:1002:
10300:error:0D07803A:asn1 encoding routines:ASN1_ITEM_EX_D2I:nested asn1
error:tasn_dec.c:305:Type=PKCS12
you might have forgotten to add the "-export" option.
You can check if you have a valid keystore with the keytool (comes with the JDK):
$> keytool -list -keystore ssl.keystore -storetype PKCS12
Enter keystore password:
Keystore type: PKCS12
Keystore provider: SunJSSE
Your keystore contains 1 entry
2, Jun 14, 2006, keyEntry,
Certificate fingerprint (MD5): CB:47:4F:56:75:23:FA:9E:9C:7B:11:D9:8C:B3:D4:1E

509 | P a g e
It's important that you have a keyEntry in there.
Authentication scenarios
In this section, we'll describe four typical SSL scenarios
 1 - SSL enabled on the server - the common case
 2 - SSL enabled on the server with self-signed client certs - aka mutual authentication -
standalone HTTP client
 3 - SSL enabled on the server with self-signed client certs - aka mutual authentication - Web
Browser Client
 4 - SSL enabled on the server with an openssl CA issued client cert - aka mutual authentication
with CA issued client cert
Setup
 Grab a copy of the latest JBossAS release and explode it.
 Download the java client client-server-certs.zip from the attachment section
 Download the http client httpclient.zip from the attachment section
 Download openssl if you don't have it so that a pkcs12 key can be generated from the client
x509 cert to import into your browser. For win32 you can download Cygwin and for nix
platforms you can either build the dist from source obtained from the OpenSSL Site or search
the web for an rpm or other binary package as required for your platform.
Use Cases
1 - SSL enabled on theserver - the common case
In this configuration you need three files
1. server.keystore - contains the key pair
2. server.cer - server certificate exported from the keystore
3. client.truststore - contains the server certificate
 Create the server keystore
keytool -genkey -alias serverkeys -keyalg RSA -keystore server.keystore -storepass 123456 -keypass 123456 -
dname "CN=localhost, OU=MYOU, O=MYORG, L=MYCITY, ST=MYSTATE, C=MY"
 Create the server certificate

510 | P a g e
keytool -export -alias serverkeys -keystore server.keystore -storepass 123456 -file server.cer
 Configure Tomcat
Copy server.keystore to /server/xxx/conf and update the following in server.xml
(For JBoss AS 4.2.1 don't forget two additional attributes: protocol="HTTP/1.1" and SSLEnabled="true".)

<Connector port="8443" address="${jboss.bind.address}"
maxThreads="100" strategy="ms" maxHttpHeaderSize="8192"
emptySessionPath="true"
scheme="https" secure="true" clientAuth="false"
sslProtocol = "TLS"
keystorePass="123456"
></Connector>
 Start the server
run -c default
 Creating client.truststore (by importing server certificate)
keytool -import -v -keystore client.truststore -storepass 123456 -file server.cer
 Run the client
java -Djavax.net.ssl.trustStore=client.truststore -Djavax.net.ssl.trustStorePassword=123456
acme/ReadHttpsURL2 https://localhost:8443
SSL enabled on the server with self-signed client certs - aka mutual authentication -
standalone HTTP client
To require that a http client presents a valid client certificate you need to add a clientAuth="true" attribute to the
Connector configuration. Depending on how what root CA has signed the client cert you may need to also specify the
truststoreFile and truststorePass for the keystore containing the client cert signer.
In this configuration you need 6 files:
1. server.keystore - contains the key pair
2. server.cer - server certificate exported from the keystore
3. client.truststore - contains the the server certificate
4. client.keystore - contains the key pair
5. client.cer - client certificate exported from the keystore
6. server.truststore - contains the client certificate

511 | P a g e
 Create the server keystore
keytool -genkey -alias serverkeys -keyalg RSA -keystore server.keystore -storepass 123456 -keypass 123456 -
dname "CN=localhost, OU=MYOU, O=MYORG, L=MYCITY, ST=MYSTATE, C=MY"
 Create the server certificate
keytool -export -alias serverkeys -keystore server.keystore -storepass 123456 -file server.cer
 Create the client keystore
keytool -genkey -alias clientkeys -keyalg RSA -keystore client.keystore -storepass 123456 -keypass 123456 -
dname "CN=localhost, OU=MYOU, O=MYORG, L=MYCITY, S=MYSTATE, C=MY"
 Create the client certificate
keytool -export -alias clientkeys -keystore client.keystore -storepass 123456 -file client.cer
 Import server certificate into client truststore
keytool -import -v -keystore client.truststore -storepass 123456 -file server.cer
 Import client certificate into server truststore
keytool -import -v -keystore server.truststore -storepass 123456 -file client.cer
 Update the Tomcat configuration
Copy both server.keystore and server.truststore to /server/xxx/conf and update the following in server.xml
NOTE: The attribute clientAuth is set to "true".

scheme="https" secure="true" clientAuth="true"
sslProtocol = "TLS"
keystorePass="123456"
truststoreFile="${jboss.server.home.dir}/conf/server.truststore"
truststorePass="123456">
</Connector>
 Start the server
run -c default

512 | P a g e
 Run the client
java -Djavax.net.ssl.keyStore=client.keystore -Djavax.net.ssl.keyStorePassword=123456
-Djavax.net.ssl.trustStore=client.truststore -Djavax.net.ssl.trustStorePassword=123456
acme/ReadHttpsURL2 https://localhost:8443
SSL enabled on the server with self-signed client certs - aka mutual authentication - Web
Browser Client
 To enable mutual authentication between the client and server, a client cert must be generated.
Both the client and server certs can be generated using the java keytool utility similar to how
step 1 was done. An issue with using the client cert in a browser is that the cert must be
imported into the browser from a key format such as pkcs12, and keytool does not currently
support this format.
 Because of this, openssl must be used to generate the required format from the keytool x509
certificate. Since there are many steps in this process, the steps have been scripted in an ant
1.6.x build.xml file that can be found in the ClientServerCerts.zip attachment. Download and
unpack this zip file to create a client-server-certs directory that contains the build.xml script.
 Cd to client-server-certs, and simply run ant to generate the client and server certs, keystores
and trustores. The output will be something like:
[starksm@banshee9100 client-server-certs]$ ant
Buildfile: build.xml
self-signed-certs:
[echo] keytool -genkey -alias clientCert -keyalg RSA -validity 730 -keystore client.keystore -dname
cn=ClientCert,o=SomeCA,ou=SomeCAOrg -keypass clientcert -storepass clientcert
[exec] Keystore type: jks
[exec] Keystore provider: SUN
[exec] Your keystore contains 1 entry
[exec] clientcert, Jun 17, 2005, keyEntry,
[exec] Certificate fingerprint (MD5): A4:60:1C:44:17:F8:B4:80:BA:BC:AA:CF:5C:E9:50:32
[echo] keytool -genkey -alias serverCert -keyalg RSA -validity 730 -keystore server.keystore -dname
cn=localhost,o=SomeCA,ou=SomeCAOrg -keypass servercert -storepass servercert
[exec] servercert, Jun 17, 2005, keyEntry,
[exec] Certificate fingerprint (MD5): E1:46:C5:54:22:6B:D6:E5:AF:E3:11:98:55:AC:17:C9

513 | P a g e
[echo] keytool -export -alias clientCert -keystore client.keystore -storepass clientcert -file client.cer
[exec] Certificate stored in file <client.cer>
[exec] Owner: CN=ClientCert, O=SomeCA, OU=SomeCAOrg
[exec] Issuer: CN=ClientCert, O=SomeCA, OU=SomeCAOrg
[exec] Serial number: 42b37131
[exec] Valid from: Fri Jun 17 17:56:17 PDT 2005 until: Sun Jun 17 17:56:17 PDT 2007
[exec] Certificate fingerprints:
[exec] MD5: A4:60:1C:44:17:F8:B4:80:BA:BC:AA:CF:5C:E9:50:32
[exec] SHA1: 29:66:59:3B:9F:9E:2B:C4:E0:1C:37:BB:7B:58:C3:DD:19:E5:DE:D4
[echo] keytool -export -alias serverCert -keystore server.keystore -storepass servercert -file server.cer
[exec] Certificate stored in file <server.cer>
[exec] Owner: CN=localhost, O=SomeCA, OU=SomeCAOrg
[exec] Issuer: CN=localhost, O=SomeCA, OU=SomeCAOrg
[exec] Valid from: Fri Jun 17 17:56:18 PDT 2005 until: Sun Jun 17 17:56:18PDT 2007
[exec] MD5: E1:46:C5:54:22:6B:D6:E5:AF:E3:11:98:55:AC:17:C9
[exec] SHA1: 12:BC:6D:D5:06:B7:49:CD:DA:F4:C2:9D:5F:3F:C2:9C:5D:AF:EA:15
[echo] keytool -import -alias serverCert -keystore client.truststore -storepass clientcert -file server.cer
[exec] Owner: CN=localhost, O=SomeCA, OU=SomeCAOrg
[exec] Issuer: CN=localhost, O=SomeCA, OU=SomeCAOrg
[exec] Trust this certificate? [no]: Certificate was added to keystore
[exec] MD5: E1:46:C5:54:22:6B:D6:E5:AF:E3:11:98:55:AC:17:C9
[exec] SHA1: 12:BC:6D:D5:06:B7:49:CD:DA:F4:C2:9D:5F:3F:C2:9C:5D:AF:EA:15
[echo] keytool -import -alias clientCert -keystore server.truststore -storepass servercert -file client.cer
[exec] Owner: CN=ClientCert, O=SomeCA, OU=SomeCAOrg
[exec] Issuer: CN=ClientCert, O=SomeCA, OU=SomeCAOrg
[exec] Trust this certificate? [no]: Certificate was added to keystore
[exec] MD5: A4:60:1C:44:17:F8:B4:80:BA:BC:AA:CF:5C:E9:50:32
[exec] SHA1: 29:66:59:3B:9F:9E:2B:C4:E0:1C:37:BB:7B:58:C3:DD:19:E5:DE:D4
[echo] client.keystore contents:
[exec] clientcert, Jun 17, 2005, keyEntry,
[exec] Certificate fingerprint (MD5): A4:60:1C:44:17:F8:B4:80:BA:BC:AA:CF:5C:E9:50:32
[echo] server.keystore contents:
[exec] servercert, Jun 17, 2005, keyEntry,
[exec] Certificate fingerprint (MD5): E1:46:C5:54:22:6B:D6:E5:AF:E3:11:98:55:AC:17:C9

514 | P a g e
BUILD SUCCESSFUL
Total time: 3 seconds
[starksm@banshee9100 client-server-certs]$ ls
build.xml client.keystore* server.cer* server.truststore*
client.cer* client.truststore* server.keystore* src/
 Next, create a pkcs12 formatted key to import into your browser. This is done by running the cer2pkcs12 target.
[starksm@banshee9100 client-server-certs]$ ant cer2pkcs12
Buildfile: build.xml
cer2pkcs12:
[mkdir] Created dir: C:tmpclient-server-certsclasses
[javac] Compiling 1 source file to C:tmpclient-server-certsclasses
[echo] openssl x509 -out client-pem.cer -outform pem -text -in client.cer -inform der
[echo] openssl pkcs12 -export -out client.p12 -inkey client.8 -in client-pem.cer -passout pass:clientcert
BUILD SUCCESSFUL
Total time: 2 seconds
[starksm@banshee9100 client-server-certs]$ ls
build.xml client.cer* client.p8* server.keystore*
classes/ client.keystore* client.truststore* server.truststore*
client-pem.cer client.p12 server.cer* src/
 The resulting client.p12 file is the pkcs12 formatted private key for the x509 client cert created in the first step. This
should be imported into your browser. For Mozilla Firefox 1.0.x, this entails selecting Tools/Options menu, selecting
the Advanced section of the options dialog, and selecting the Manage Certificates... button to display the import
dialog. The client.p12 password to use for the import is "clientcert", without the quotes.
 You should also import the server.cer x509 cert into the Authorities section so that the server's self signed cert is seen
as trusted. Otherwise, the browser should prompt you about an untrusted server cert when you try an https
connection.
 Next, copy the server.keystore and server.truststore to the jboss server/default/conf directory, or the conf directory
of whatever server configuration you are using.
 Next, edit the deploy/jbossweb-tomcat55.sar/server.xml file to enable the SSL connector. The Connector element
should look like the following, with clientAuth="true" to require that clients provide a certificate.

protocol="HTTP/1.1" SSLEnabled="true"
scheme="https" secure="true" clientAuth="true"
keystorePass="servercert"
truststoreFile="${jboss.server.home.dir}/conf/server.truststore"
truststorePass="servercert"
sslProtocol = "TLS">
</Connector>
 You should now be able to connect to the jboss server using https and the browser should display a dialog asking for
the cert to use (unless the browser is configured to do this automatically). An example of the dialog from the Firefox
1.0.4 browser is shown here:


515 | P a g e
4 - SSL enabled on theserver with an openssl CA issued client cert -aka mutual
authentication with CA issued client cert
 Install openssl and configure its CA
First, you need to configure the certificate authority application of OpenSSL. churchillobjects.com has a good
overview of the required steps in the Generating a Certificate Authority article. See the ca manpage for the full details
of the OpenSSL ca command.
 Create server openssl CA signed cert using keytool
[starksm@banshee9100 openssl-ca]$ keytool -genkey -alias unit-tests-server -keystore localhost.keystore
Enter keystore password: unit-tests-server
What is your first and last name?
[Unknown]: localhost
What is the name of your organizational unit?
[Unknown]: QA
What is the name of your organization?
[Unknown]: JBoss Inc.
What is the name of your City or Locality?
[Unknown]: Snoqualmie Pass
What is the name of your State or Province?
[Unknown]: Washington
What is the two-letter country code for this unit?
[Unknown]: US

516 | P a g e
Is CN=localhost, OU=QA, O=JBoss Inc., L=Snoqualmie Pass, ST=Washington, C=US correct?
[no]: yes
Enter key password for <unit-tests-server>
(RETURN if same as keystore password):
 Create a cert signing request for the server key
[starksm@banshee9100 conf]$ keytool -keystore localhost.keystore -certreq -alias unit-tests-server -file unit-
tests-server.csr
 Sign the cert request
[starksm@banshee9100 openssl-ca]$ openssl ca -config openssl.cnf -in unit-tests
-server.csr -out unit-tests-server.pem
Using configuration from openssl.cnf
Enter pass phrase for ./private/cakey.pem: openssl-ca
DEBUG[load_index]: unique_subject = "no"
Check that the request matches the signature
Signature ok
The Subject's Distinguished Name is as follows
countryName PRINTABLE:'US'
stateOrProvinceName PRINTABLE:'Washington'
localityName PRINTABLE:'Snoqualmie Pass'
organizationName PRINTABLE:'JBoss Inc.'
organizationalUnitName:PRINTABLE:'QA'
commonName PRINTABLE:'localhost'
Certificate is to be certified until Jul 30 21:39:21 2005 GMT (365 days)
Sign the certificate? [y/n]:y
1 out of 1 certificate requests certified, commit? [y/n]y
Write out database with 1 new entries
Data Base Updated
 Convert to DER
[starksm@banshee9100 openssl-ca]$ openssl x509 -in unit-tests-server.pem -out unit-tests-server.cer
 import CA root to keystore
[starksm@banshee9100 openssl-ca]$ keytool -keystore localhost.keystore -alias openssl-ca -import -file
cacert.pem
Owner: CN=jboss.com, C=US, ST=Washington, L=Snoqualmie Pass, EMAILADDRESS=admin@
jboss.com, OU=QA, O=JBoss Inc.
Issuer: CN=jboss.com, C=US, ST=Washington, L=Snoqualmie Pass, EMAILADDRESS=admin
@jboss.com, OU=QA, O=JBoss Inc.
Serial number: 0
Valid from: Wed May 26 00:53:20 PDT 2004 until: Sat May 24 00:53:20 PDT 2014
Certificate fingerprints:

517 | P a g e
MD5: B3:34:05:D0:7D:7E:18:A5:E3:0B:82:0A:D9:54:41:7E
SHA1: F0:85:B4:14:8C:4E:92:CB:68:E6:D6:08:DC:86:94:E5:BF:DC:58:32
Trust this certificate? [no]: yes
Certificate was added to keystore
 Import CA reply
[starksm@banshee9100 openssl-ca]$ keytool -keystore localhost.keystore -alias unit-tests-server -import -file
unit-tests-server.cer
Certificate reply was installed in keystore
[starksm@banshee9100 openssl-ca]$ ls -l localhost.keystore
-rwxrwxrwx 1 starksm None 3247 Jul 30 14:44 localhost.keystore*
[starksm@banshee9100 openssl-ca]$ keytool -list -keystore localhost.keystore
Keystore type: jks
Keystore provider: SUN
Your keystore contains 2 entries
unit-tests-server, Jul 30, 2004, keyEntry,
Certificate fingerprint (MD5): 34:35:A5:4A:EB:F3:3C:F8:60:C1:86:05:07:01:4B:DD
openssl-ca, Jul 30, 2004, trustedCertEntry,
Certificate fingerprint (MD5): B3:34:05:D0:7D:7E:18:A5:E3:0B:82:0A:D9:54:41:7E
 Import the client cert
[starksm@banshee9100 openssl-ca]$ keytool -import -keystore localhost.keystore -alias unit-tests-client -file
unit-tests-client.cer
Certificate was added to keystore
[starksm@banshee9100 openssl-ca]$ keytool -list -keystore localhost.keystore
Keystore type: jks
Keystore provider: SUN
Your keystore contains 3 entries
unit-tests-client, Jul 30, 2004, trustedCertEntry,
Certificate fingerprint (MD5): 4A:9C:2B:CD:1B:50:AA:85:DD:89:F6:1D:F5:AF:9E:AB
unit-tests-server, Jul 30, 2004, keyEntry,
Certificate fingerprint (MD5): 34:35:A5:4A:EB:F3:3C:F8:60:C1:86:05:07:01:4B:DD
openssl-ca, Jul 30, 2004, trustedCertEntry,
Certificate fingerprint (MD5): B3:34:05:D0:7D:7E:18:A5:E3:0B:82:0A:D9:54:41:7E
[starksm@banshee9100 openssl-ca]$
Another (untested) keystore/openssl recipe:
Create Keystore certificate:

518 | P a g e
1. keytool -genkey -keystore {keystore location} -keyalg RSA -alias postgresql -dname "cn=www.beyarecords.com,
ou=Music, o=Urban Music, c=GB" -keystore ~/postgresql -validity 365
2. keytool -selfcert -keystore {keystore location} -alias postgresql
3. keytool -export -keystore {keystore location} -alias postgresql -rfc -file postgresql.cer
4. keytool -import -keystore {keystore location} -alias postgresql -file postgresql.cer
Export private key from keystore alias:
1. java ExportPrivateKey <keystore> <alias> <password> > exported-pkcs8.key
2. openssl pkcs8 -inform PEM -nocrypt -in exported-pkcs8.key -out postgresql.key
Note: main keystore location on OS X is: /library/java/home/lib/security/cacerts
The ExportPrivateKey class:
package security;
import java.io.File;
import java.io.FileInputStream;
import java.security.Key;
import java.security.KeyPair;
import java.security.KeyStore;
import java.security.KeyStoreException;
import java.security.NoSuchAlgorithmException;
import java.security.PrivateKey;
import java.security.PublicKey;
import java.security.UnrecoverableKeyException;
import java.security.cert.Certificate;
import sun.misc.BASE64Encoder;
public class ExportPrivateKey
{
public static void main(String args[]) throws Exception
{
for (int i = 0; i < args.length; i++)
{
System.out.println(i + ": " + args);
}
if (args.length < 2)
{
//Yes I know this sucks (the password is visible to other users via ps
// but this was a quick-n-dirty fix to export from a keystore to pkcs12
// someday I may fix, but for now it'll have to do.
System.err.println("Usage: java ExportPriv <keystore> <alias> <password>");
System.exit(1);
}
ExportPrivateKey myep = new ExportPrivateKey();
myep.doit(args[0], args[1], args[2]);
}
public void doit(String fileName, String aliasName, String pass) throws Exception
{

519 | P a g e
KeyStore ks = KeyStore.getInstance("JKS");
char[] passPhrase = pass.toCharArray();
BASE64Encoder myB64 = new BASE64Encoder();
File certificateFile = new File(fileName);
ks.load(new FileInputStream(certificateFile), passPhrase);
KeyPair kp = getPrivateKey(ks, aliasName, passPhrase);
PrivateKey privKey = kp.getPrivate();
String b64 = myB64.encode(privKey.getEncoded());
System.out.println("-----BEGIN PRIVATE KEY-----");
System.out.println(b64);
System.out.println("-----END PRIVATE KEY-----");
}
// From http://javaalmanac.com/egs/java.security/GetKeyFromKs.html
public KeyPair getPrivateKey(KeyStore keystore, String alias, char[] password)
{
try
{
// Get private key
Key key = keystore.getKey(alias, password);
if (key instanceof PrivateKey)
{
// Get certificate of public key
Certificate cert = keystore.getCertificate(alias);
// Get public key
PublicKey publicKey = cert.getPublicKey();
// Return a key pair
return new KeyPair(publicKey, (PrivateKey) key);
}
}
catch (UnrecoverableKeyException e)
{
}
catch (NoSuchAlgorithmException e)
{
}
catch (KeyStoreException e)
{
}
return null;
}
}

520 | P a g e
More Info
Another guide to creating certificates using OpenSSL and JBoss Setup - Creating an SSL Keystore
Using the Java Keytool
References
 JavaTM Secure Socket Extension (JSSE) Reference Guide
 Security chapter from JBoss Development and Administration book
Attachments:
 client-server-certs.zip (3.4 K)
 httpclient.zip (1.3 K)
Limiting client access using Tomcat (Engine, Host, or Context level)
When securing HTTP traffic, you may wish to consider limiting access to clients with a certain IP address. You can do
this at many levels. To limit client access at a high level, such as the entire server, you may use a Tomcat valve.
Tomcat has two valves that filter traffic based on the client IP addresses. They are the RemoteAddrValveand
the RemoteHostValve. Both of these valves are extended from RequestFilterValve.
For a discussion of how to configure Tomcat valves see http://tomcat.apache.org/tomcat-5.5-
doc/config/host.html (Tomcat 5.5) or http://tomcat.apache.org/tomcat-6.0-doc/config/host.html (Tomcat 6.0).
Note: The documentation on using these valves when Tomcat is embedded in JBoss is confusing, but it is simple to
do. Although Tomcat scans various directories for context.xml.default and context.xml for defaults, to set a valve on
a single Tomcat /context you need WEB-INF/context.xml in the application's WAR.
An example of context.xml that allows accesses from 127.0.0.x and 10.x.x.x:
<?xml version="1.0"?>
<Context debug="1" privileged="true" >
<Valve className="org.apache.catalina.valves.RemoteAddrValve"
allow="127.0.0.d{1,3},10.d{1,3}.d{1,3}.d{1,3}"
deny="" />
</Context>
For more discussions on context.xml, see Web-App Context Configuration.
No editing of the Tomcat server.xml is required unless you're applying valves to Hosts. In the latter, edit either
server.xml or jboss-service.xml based on JBoss version:

521 | P a g e
JBoss versions server.xml or jboss-service.xml
4.2.0 and higher <jboss install dir>/server/<configuration>/deploy/jboss-web.deployer/server.xml
3.2.4 and 4.0.x <jboss install dir>/server/<configuration>/deploy/jbossweb-tomcat50.sar/server.xml
3.2.3 and lower <jboss install dir>/server/<configuration>/deploy/jbossweb-tomcat41.sar/META-INF/jboss-server.xml
Limiting client accessusing a servlet filter (Servlet orurl-pattern level)
To limit client access to a particular servlet or to requests that match a url pattern, you can use the servlet filter
attached to this page. This requires JDK 1.4 or higher.
To install, place the attached jar in your WEB-INF/lib directory. If you want to use it in multiple web applications then
you can instead put it in your
The attached web.xml file is an example that shows how to configure the filter. The main thing to look at is the filter
definition:
<filter>
<filter-name>RemoteHostFilter</filter-name>
<filter-class>org.jboss.remotehostfilter.RemoteHostFilter</filter-class>
<init-param>
<param-name>deny</param-name>
<param-value>150.0.0.*</param-value>
</init-param>
<init-param>
<param-name>allow</param-name>
<param-value>192.4.5.6,127.0.0.*</param-value>
</init-param>
</filter>
This filter is configured by setting the "allow" and/or "deny" properties to a comma-delimited list of regular
expressions(in the syntax supported by the java.util.regex package) to which the client IP address will be compared.
Evaluation proceeds as follows:
 If there are any deny expressions configured, the IP will be compared to each expression. If a match is found, this
request will be rejected with a "Forbidden" HTTP response.
 If there are any allow expressions configured, the IP will be compared to each such expression. If a match is NOT
found, this request will be rejected with a "Forbidden" HTTP response.
 Otherwise, the request will continue normally.
Don't forget to add an appropriate "filter-mapping" element, or this filter will never be applied.
Attachments:
 web.xml (1.5 K)
 hostfilter.jar (3.7 K)

522 | P a g e
 RemoteHostFilter.java (5.1 K)
 TestServlet.java (2.5 K)
ConfiguringAJavaSecurityManager
How to Run JBoss with a Java Security Manager
By default the JBoss server does not start with a Java 2 security manager. If you want to restrict privileges of code
using Java 2 permissions you need to configure the JBoss server to run under a security manager. This is done by
configuring the Java VM options in the run.bat or run.sh scripts in the JBoss server distribution bin directory. The two
required VM options are as follows:
 java.security.manager: This is used without any value to specify that the default security manager should be used.
This is the preferred security manager. You can also pass a value to the java.security.manager option to specify a
custom security manager implementation. The value must be the fully qualified class name of a subclass of
java.lang.SecurityManager. This form specifies that the policy file should augment the default security policy as
configured by the VM installation.
 java.security.policy: This is used to specify the policy file that will augment the default security policy information for
the VM. This option takes two forms: java.security.policy=policyFileURL and java.security.policy==policyFileURL. The
first form specifies that the policy file should augment the default security policy as configured by the VM installation.
The second form specifies that only the indicated policy file should be used. The policyFileURL value can be any URL
for which a protocol handler exists, or a file path specification.
Both the run.bat and run.sh start scripts reference an JAVA_OPTS variable which you can use to set the security
manager properties.
Enabling Java 2 security is the easy part. The difficult part of Java 2 security is establishing the allowed permissions. A
sample server.policy file that is used as part of the testsuite is the following:
// The Java2 security policy for the securitymgr tests
// Install with -Djava.security.policy==server.policy
// and -Djboss.home.dir=path_to_jboss_distribution
// and -Djboss.server.home.dir=path_to_jboss_server_home
// Trusted core Java code
grant codeBase "file:${java.home}/lib/ext/-" {
permission java.security.AllPermission;
};
grant codeBase "file:${java.home}/lib/*" {
};
// For java.home pointing to the JDK jre directory
grant codeBase "file:${java.home}/../lib/*" {
};
// Trusted core Jboss code
grant codeBase "file:${jboss.home.dir}/bin/-" {
};
grant codeBase "file:${jboss.home.dir}/lib/-" {

523 | P a g e
};
grant codeBase "file:${jboss.server.home.dir}/lib/-" {
};
grant codeBase "file:${jboss.server.home.dir}/deploy/-" {
};
grant codeBase "file:${jboss.server.home.dir}/work/-" {
};
// Minimal permissions are allowed to everyone else
grant {
permission java.util.PropertyPermission "*", "read";
permission java.lang.RuntimePermission "queuePrintJob";
permission java.net.SocketPermission "*", "connect";
permission java.lang.RuntimePermission "accessClassInPackage.*";
permission java.lang.RuntimePermission "org.jboss.security.SecurityAssociation.getSubject";
permission javax.management.MBeanServerPermission "findMBeanServer";
permission javax.management.MBeanPermission
"org.jboss.mx.modelmbean.XMBean#*[JMImplementation:type=MBeanRegistry]", "*";
permission javax.security.auth.AuthPermission "createLoginContext.*";
};
An example JAVA_OPTS enhancement example is:
JAVA_OPTS="$JAVA_OPTS -Djava.security.manager -
Djava.security.policy=${build.resources}/securitymgr/server.policy"
JAVA_OPTS="$JAVA_OPTS -Djboss.home.dir=/releases/jboss-4.0.3SP1"
JAVA_OPTS="$JAVA_OPTS -Djboss.server.home.dir=/releases/jboss-4.0.3SP1/server/default"
Client applications should be deployed outside of the server distribution or under a directory other than
${jboss.server.home.dir}/deploy to only receive the minimal permissions grant, and this URL added to the
URLDeploymentScanner URLs attribute conf:

<mbean code="org.jboss.deployment.scanner.URLDeploymentScanner"
name="jboss.deployment:type=DeploymentScanner,flavor=URL">
...
<attribute name="URLs">
deploy/,apps-deploy/
</attribute>
This would pickup deployments from the usual ${jboss.server.home.dir}/deploy directory as well as from a custom
${jboss.server.home.dir}/apps-deploy directory.
SetUpAMysqlDatasource

524 | P a g e
Setting up a MySQL datasource
Download the driver
 First, http://www.mysql.com/products/connector/j/ appropriate for your edition of mySQL.
 Next, untar/unzip it and extract the jar file.
 Copy the jar file into $JBOSS_HOME/server/xxx/lib, where xxx is your config name (such as "default") NOTE: For JBoss
4.0.2, use the jar file mysql-connector-java-3.1.8-bin.jar, not mysql-connector-java-3.1.8-bin-g.jar.
 Copy the $JBOSS_HOME/docs/examples/jca/mysql-ds.xml file to $JBOSS_HOME/server/xxx/deploy
Configure the datasource
 Edit the mysql-ds.xml file.
 Replace <jndi-name>MySqlDS</jndi-name> with your datasource name. If you choose to make mySQL your default
database (DefaultDS), then call this DefaultDS and be sure to delete the example
$JBOSS_HOME/server/all/deploy/hsqldb-ds.xml which is also configured to be DefaultDS.
 Replace <connection-url>jdbc:mysql://mysql-hostname:3306/jbossdb</connection-url> with your connection
string. Generally you just need to replace mysql-hostname with your host. Be sure that your user has permission to
connect to that hostname.
 Set the user-name and hostname elements to your database username and hostname
Advanced options for the MySQL Driver can be set with <connection-property name="property">value</connection-
property>.
Refer to MySQL Connector/J Manual Chapter 2 for more Information.
Named pipes
Under Windows NT/2000/XP you can connect to the MySQL Server via named pipes if the MySQL server and JBoss are
running on the same machine. Following the Connector/J documentation this is 30%-50% faster than TCP/IP access.
 Set the opion enable-named-pipe in the my.ini and restart the MySQL Server (the server variable named_pipe must
be ON)
 Set the Property socketFactory to com.mysql.jdbc.NamedPipeSocketFactory
 Set the JDBC URL to jdbc:mysql://./databasename
Automatic reconnect
WARNING: DO NOT ENABLE AUTO RECONNECT IF YOU ARE USING MANAGED TRANSACTIONS
The auto reconnect does not preserve transaction state in the database.
It is ok if you are ALWAYS using auto-commit=true.
 autoReconnect (default = false) Set the driver to reconnect if the MySQL Server fails.
 maxReconnects (default = 3) Maximum number of connection attembts.
 initialTimeout (default = 2) Delay in seconds between connection atembts

525 | P a g e
JBossMQ
 First copy $JBOSS_HOME/docs/examples/jms/mysql-jdbc2-service.xml to $JBOSS_HOME/server/xxx/deploy/jms
 Delete hsqldb-jdbc2-service.xml from $JBOSS_HOME/server/xxx/deploy/jms
 NOTE: If you made mysql your DefaultDS above, you need to edit $JBOSS_HOME/server/xx/deploy/jms/mysql-jdbc2-
service.xml and set the DataSourceBinding.name by replacing <depends optional-attribute-
name="ConnectionManager">jboss.jca:service=DataSourceBinding,name=MySqlDS</depends> with <depends
optional-attribute-name="ConnectionManager">jboss.jca:service=DataSourceBinding,name=DefaultDS</depends>
 NOTE: The maximum length for JMS destinations in the example mysql-jdbc2-service.xml file in JBoss 4.0.2 is 150
characters. This is typically too short to contain the full destination name, especially if a message selector is
involved. You may need to alter the CREATE_MESSAGE_TABLE line so that the maximum length of the DESTINATION
column is 255 characters. Alternately, for even longer names, make it a TEXT column type and specify a maximum
length of 255 to use in the primary key. That is:
CREATE_MESSAGE_TABLE = CREATE TABLE JMS_MESSAGES (MESSAGEID INTEGER NOT NULL, DESTINATION
VARCHAR(255) NOT NULL, TXID INTEGER, TXOP CHAR(1), MESSAGEBLOB LONGBLOB, PRIMARY KEY (MESSAGEID,
DESTINATION))
Or
CREATE_MESSAGE_TABLE = CREATE TABLE JMS_MESSAGES (MESSAGEID INTEGER NOT NULL, DESTINATION TEXT NOT
NULL, TXID INTEGER, TXOP CHAR(1), MESSAGEBLOB LONGBLOB, PRIMARY KEY (MESSAGEID, DESTINATION(255)))
Troubleshooting
 If you get connection or password errors, it is most likely an issue of permissions to the hostname supplied. See
the http://dev.mysql.com/doc/mysql/en/Adding_users.html.
 If you try connecting to "localhost" and keep getting permission errors regarding "localhost.localdomain", you're
running redhat Linux. There are a variety of potential causes--please visit the MySQL documentation on Access
Denied Causes for more information.
 If you get errors regarding creating the tables while deploying an entity bean, then perhaps your user doesn't have
permission to create tables in that database. You can grant the user
.. Seehttp://dev.mysql.com/doc/mysql/en/Adding_users.html for more information.
Examples
MySQLserver on localhostwith TCP/IP connectionon port3306 andautoReconnect
enabled
This is a bad idea, it is ok for no-tx-datasource.
<datasources>
<local-tx-datasource>
<jndi-name>MySqlDS</jndi-name>
<connection-url>jdbc:mysql://localhost:3306/database</connection-url>
<driver-class>com.mysql.jdbc.Driver</driver-class>

526 | P a g e
<user-name>username</user-name>
<password>secret</password>
<connection-property name="autoReconnect">true</connection-property>

<metadata>
<type-mapping>mySQL</type-mapping>
</metadata>
</local-tx-datasource>
</datasources>
MySQLserver on localhostwith connection over Named Pipe
<datasources>
<local-tx-datasource>
<jndi-name>MySQLDS</jndi-name>
<connection-url>jdbc:mysql://./database</connection-url>
<driver-class>com.mysql.jdbc.Driver</driver-class>
<user-name>username</user-name>
<password>secret</password>
<connection-property name="socketFactory">com.mysql.jdbc.NamedPipeSocketFactory</connection-
property>

<metadata>
<type-mapping>mySQL</type-mapping>
</metadata>
</local-tx-datasource>
</datasources>
jGuard
jGuard is a library that provides EASY security (authentication and authorization) for Java web
applications.
It is built over the stable and mature JAAS framework, which is part of the JAVA J2SE api.

527 | P a g e
jGuard is very flexible and allows several different ways to configure those mechanisms for
authentication and authorization, i.e., in a relational database, XML files, or LDAP service. See
documentation for more details.
jBoss
o jGuard 0.80 has been successfully tested with jBoss 4.0.3
o Be sure that 'includeOldConfig' in your jguard xml configuration is set to "true".
o Edit in your jboss JBOSS_HOME/server/ZZZ/conf/login-config.xml
o Add this in the policy markup:
<application-policy name="jGuardExample">
<authentication>
<login-module code="org.jboss.security.auth.spi.ProxyLoginModule" flag="required" />
</authentication>
</application-policy>
You will have some errors in the log because UsersRolesLoginModule in not configured but it has no
consequences on your applications.
o jGuard 0.70 alpha 2 has been succesfully tested on jBoss 4.03 with SUN's JDK 1.5.0_04.
the jGuard-jvm-x.xx.jar should be placed in
the {JBOSS_HOME}/server/default/lib directory. jGuardExample.war archive has been placed in
the {JBOSS_HOME}/server/default/deploy directory.
o jGuard 0.70 alpha 2 has been succesfully tested on jBoss 3.2.7 with SUN's JDK 1.5.0_04.
the jGuard-jvm-x.xx.jar should be placed in
the {JBOSS_HOME}/server/default/lib directory. jGuardExample.war archive has been placed in
the {JBOSS_HOME}/server/default/deploy directory. in the jBoss 3.x.x series,application server is
configured to used by default the UnifiedClassLoader which is not j2ee compliant.jGuard requires
that you configure JBoss to use classloaders in a j2ee compliant manner: open the file called jboss-
service.xml located in the ${JBOSS_HOME}/server/default/deploy/jbossweb-tomcat50.sar/META-
INF/ directory. locate the attribute called UseJBossWebLoader and change its value
from true to false.
o For a successful deployment of jGuardExample.war version 0.65.5 on JBoss 3.2.7, it is necessary
to set the login module to "org.jboss.security.auth.spi.ProxyLoginModule" (with all options
reported in web.xml) as application policy for "jGuardExample".This setting overrides the
default application policy, that uses the "org.jboss.security.auth.spi.UsersRolesLoginModule"

528 | P a g e
DWR
DWR, or Direct Web Remoting, is a Java open source library that helps developers write web sites that
include Ajax technology. It allows code in a web browser to use Java functions running on a web server as
if those functions were within the browser.
It consists of two main parts:
 Code to allow JavaScript to retrieve data from a servlet-based web server using Ajax principles.
 A JavaScript library that makes it easier for the web site developer to dynamically update the web
page with the retrieved data.
DWR takes a novel approach to Ajax by dynamically generating JavaScript code based on Java
classes.[1]
Thus the web developer can use Java code from JavaScript as if it were local to the web
browser; whereas in reality the Java code runs in the web server and has full access to web server
resources. For security reasons the web developer must configure exactly which Java classes are safe to
export (which is often called web.xml or dwr.xml).
This method of remoting functions from Java to JavaScript gives DWR users a feel much like
conventional RPC mechanisms like RMI or SOAP, with the benefit that it runs over the web without
requiring web browser plug-ins.
DWR does not consider the web browser / web server protocol to be important, and prefers to ensure
that the programmer's interface is natural. The greatest challenge to this is to marry the asynchronous
nature of Ajax with the synchronous nature of normal Java method calls.
In the asynchronous model, result data is only available some time after the initial call is made. DWR
solves this problem by allowing the web developer to specify a function to be called when the data is
returned using an extra method parameter.This extra method is called CallBack Method.
Here is a sample Callback:
MJavaClassOnJs.getListProducts(selectedCategory,{
callback:function(returnedList){
dwr.util.addOptions(myComboId,returnedList,"productId","productName")
}
})
The callback is that function inside the Json object passed as an additional parameter to the remoted
function.

529 | P a g e
With version 2.0 DWR supports Reverse Ajax[1]
where Java code running on the server can deliberately
send dedicated JavaScript to a browser.
Joe Walker started the DWR project in 2004.
securing DWR with jGuard
Last modified by XWikiGuest on 2010/10/29 06:33
Comments (0) | Attachments (0) | History | Information
jguard 1.0.0 support securization of webapps using * DWR 1.x* .
we plan to support also *DWR 2.x * hopefully in the 1.1.0 release.
install DWR in the webapp
in a classic way,to install DWR, you have to insert in your web.xml file, a DWR servlet :
dwr-invoker
DWR Servlet
uk.ltd.getahead.dwr.DWRServlet
debug
true
dwr-invoker
/dwr/*
but we will configure it in a more advanced way at the bottom of this document.
DWR.xml
DWR permits to access directly tobeans hosted on the server in the webapp. central configuration
file is DWR.xml. for example, if you want to permit access to the bean
net.sf.jguard.example.dwr.Dummy, you have to configure it in DWR.xml like this:
DWR1Permission : a dedicated Permission
jguard 1.0.0 ships a Permission dedicated to DWR 1.x. this permission has got a name and some
paraemters, like any subclass of java.security.BasicPermisison:
o name
used to put on the permission functional meaning
o parameters
o first parameter: class of the Creator used to instantiate the related protected beans

530 | P a g e
example: uk.ltd.getahead.dwr.create.NewCreator
o
o second parameter: the class of the bean to protect
example: net.sf.jguard.example.dwr.Dummy
o
o third parameter : the method to protect
example: getHello
you can use it either in database or in jGuardPrincipaslPermissions.xml file.
.......
dummy
net.sf.jguard.jee.extras.dwr1.DWR1Permission
uk.ltd.getahead.dwr.create.NewCreator
net.sf.jguard.example.dwr.Dummy
getHello
.......
DWR1AccessControl
now, we need to link access to Dummy bean via DWR with jGuard. to do that, you have to insert one
more parameter of the DWR servlet configured previously like this:
dwr-invoker
DWR Servlet
uk.ltd.getahead.dwr.DWRServlet
debug
true
uk.ltd.getahead.dwr.AccessControl
net.sf.jguard.jee.extras.dwr1.DWR1AccessControl
dwr-invoker
/dwr/*
what's about jGuard and DWR interactions?
you have to notice that jGuard is linked with the DWR1AccessControl. it is used to delegate to jGuard
authorization check before the user access via a javascript instruction to the java Bean declared in
the DWR.xml file.
but you have to configure jGuard to authenticate the user. to do that, accessFilter has to be used.
so, AccessFilter and its mapped URIs(like all struts actions *.do) will be used for Authentication, and
authorization checks with your traditional web framework(for example Struts).
DWR will be used for ajax interactions, and will delegate authorization check to jGuard.

531 | P a g e
so,in an application hosting Struts and DWR, authentication will be done in a URI ending by .do, and
authorization checks will be done in uri ending by .do and containing the DWR pattern (see servlet
mappings configured above).
Chapter 3. security architecture
Table of Contents
3.1. securing an application
3.1.1. java security architecture
3.2. Which jGuard security scopes?
3.2.1. jGuard and jee users
3.2.2. security scopes
3.3. debugging
3.4. configuration files
3.4.1. configuration files used in every context (standalone and web applications)
3.1. securing an application
securing an application should be done with anAccess Control Model. widely used access control models are
described in a dedicated chapter.
To apply an access control model in a java application, you have these choices:
 use java security infrastructure (through jAAS)
 use security implementation by the application server if you're in a jee context
 reinvent the wheel
3.1.1. java security architecture
3.1.1.1. java security roots
overall Java security stands on the java.lang.SecurityManager implementation in place on theJVM, and on the
java.security file located in in${java.home}/lib/security/.

532 | P a g e
3.1.1.2. overall architecture
3.1.1.2.1.
One application need to have an Authentication part and an Authorization part initialized. It implies for the
authentication part, a javax.security.auth.Configuration instance defined, and for the Authorization part
a java.security.Policyinstance (or an isolated part of an instance). jGuard provides a single point of access with its
PolicyEnforcementPoint.
Note
in a JEE environement, Authentication and Authorization parts are set by the ContextListener class from jGuard.
Specific technology parts are minimized. So, integrating a new technology in jGuard implies implementing
a Technology anchor, an AuthorizationBindings implementation, and eventually anAuthenticationBindings(not always
needed if authentication is done via another technology anchor and scopes).
jGuard provides also some management APIs for the Authentication Part (AuthenticationManager), and for the
Authorization part (AuthorizationManager).

533 | P a g e
3.1.1.2.2. one application to bring them all
jGuard permits for one application, to use different technology anchors simultaneously. It implies that they share the
same Configuration and Policy (i.e Authentication and Authorization parts). You can see on the above diagram, that all
technology anchors provided by jGuard, uses each one a PolicyEnforcementPoint instance.this class acts as a Single
Point of Access.
Caution
be aware that tosecure access of your application, you need to configure technology anchors to force all users to pass
through them to access to protected resources. For example, in a webapp, you need to configure theweb.xml file to
enforce user to access to a technology anchor before reach the desired resource.
3.2. Which jGuard security scopes?
3.2.1. jGuard and jee users
jGuard envisions 3 types of "users" in a J2EE environment:
 administrator
 webapp developer
 webapp user
3.2.2. security scopes
jGuard provides two Security scopes, on authentication and authorization. these scopes affect
jGuard javax.security.auth.login.Configuration and java.security.policy implementations.

534 | P a g e
3.2.2.1. local security scope
this scope permits to have isolate security per classloader; i.e is mainly dedicated to jee applications.
'local' authentication provides a good security level. It allows protection of the webapp resources against webapp
users. Each webapp user will be authenticated, and access control will be provided according to his roles. This
authentication configuration will not protect webapp developers against webapp developers of others webapps, or
administrators.
The authentication configuration is easier, because everything should be configured in the web.xml. There is no need
to configure things on the JVM side. Security is present after the first webapp which uses jGuard is loaded by the
application server. This security level is reliable for these use cases:
 The webapp is used to test jGuard
 There is only one webapp on the application server
 There are multiple webapps on the same application servers, and there are 'friendly' each others
 One 'friendly' webapp is loaded firstly
3.2.2.2. jvm security scope
'advanced' configuration allows for a more secure environment, but is more difficult to configure: in jee environment,
You must install two jars: one for the webapp, and one dedicated to the JVM-side.some bootclasspath tricks are
needed too.
This configuration allows for protection of webapp resources against users like the 'usual' configuration; i.e to protect
webapp developers against others webapps, and to protect administrator against any webapp developers. The
administrator of the machine should also restrict the java rights to protect against the application sever
administrator. This configuration is highly secure, and should be used by hosting companies.
This is acascading security delegation model:
 webapp users are controlled by webapps
 webapps are isolated from others webapps (others webapps cannot make tedamages)
 webapps are controlled by the application server administrator which configure the JVM security
 The application server administrator is controlled by the operating system administrator which assign
restricted rights to java
 the operating system administrator security relies on BIOS security, which relies on the physical machine
security.
To have this very secured configuration, you must enable theSecurityManager.
3.3. debugging
for security reason, jGuard prevent by default, the application to throw to the end-user a java.lang.Throwable (i.e
a java.lang.Exception or a java.lang.Error) instance, and its included stack trace: it permits to restrain sensitive
information included in the stack trace, like the libraries you use, name of classes and methods and so on....
But, in the development stage, it can be useful to inhibit this default mechanism, for a quicker diagnostic when a
problem is present. it can be done by including the parameters of the technology anchor (like the AccessFilter in
servlet-related anchor, or the AccessListener for the JSF-based one),a propagateThrowable option to true.

535 | P a g e
3.4. configuration files
3.4.1. configuration files used in every context (standalone and
web applications)
3.4.1.1. jGuardFilter.xml
goals of this configuration file is to define:
 resources where the user is dispatched depending on the Access Control check result
 authentication schemes used with the specific technology anchor
 specific parameters for the CallbackHandler implementation
3.4.1.1.1. authentication schemes
Authentication schemes are defined as the mechanisms used to transmit credentials from the user (browser for
webapps) to the server. These credentials are used on the server to authenticate the user in its backend. They can be
configured in the authScheme markup.
Caution
to configure your authentication schemes, you DON'T have to configure your application server to use them
(especially, you DON'T have to configure the <login-config> markup in the web.xml, and its related <auth-
method> and <realm-name> markup). jGuard replace the specific mechanisms used in your application
server, to grab credentials and compute them to authenticate the user.
 FORM authentication
since its inception, jGuard support the FORM authentication scheme. Credentials are sent from the
browser to the application server through an HTML form.
some special URIs are involved in this authentication scheme:
 logonURI
this URI is used to access to the page which contains the form used to authenticate. This URI is
granted to ALL users.
 logonProcessURI
this URI is used to send to the server the credentials to authenticate. This URI is granted to ALL
users.
 loginField
HTML field in the HTML authentication form, used to store your login. This special field is trapped
by the accessFilter to grab this credential.
 passwordField
HTML field in the HTML authentication form, used to store your password. This special field is
trapped by the accessFilter to grab this credential.
Example 3.1. how to configure FORM authentication
<authScheme>FORM</authScheme>

536 | P a g e
 BASIC authentication
jGuard support BASIC authentication. Some special URIs are involved in this authentication scheme:
 logonProcessURI
this URI is used to send to the server the credentials to authenticate. This URI is granted to ALL
users.
Example 3.2. how to configure BASIC authentication
<authScheme>BASIC</authScheme>
 Digest Authentication
this authentication scheme is not yet supported.a feature request has been posted on the jGuard bug
tracking system hosted on sourceforge.
 CLIENT_CERT authentication
jGuard support CLIENT_CERT authentication.
Example 3.3. how to configure CLIENT_CERT authentication
<authScheme>CLIENT_CERT</authScheme>
Note
jGuard use its own mechanisms involved in authentication schemes. But it uses the SSL mechanism provided by the
application server, in the case of CLIENT-CERT authentication. So, you have to configure yourweb.xml file with this
markup:
<security-constraint>
<web-resource-collection>
<web-resource-name>all the webapp</web-resource-name>
<description></description>
<url-pattern>/*</url-pattern>
</web-resource-collection>
<user-data-constraint>
<description>This part requires SSL</description>
<transport-guarantee>CONFIDENTIAL</transport-guarantee>
</user-data-constraint>

537 | P a g e
</security-constraint>
3.4.1.1.2. example
Example 3.4. jGuardFilter.xml example
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<!DOCTYPE configuration SYSTEM "jGuardFilter_1.1.0.dtd">
<configuration>

<authenticationSucceedURI>/index.jsp</authenticationSucceedURI>

<authenticationFailedURI>/AuthenticationFailed.do</authenticationFailedURI>

<logonURI>/Logon.do</logonURI>

<logonProcessURI>/LogonProcess.do</logonProcessURI>
<registerURI>/Registration.do</registerURI>
<registerProcessURI>/RegistrationProcess.do</registerProcessURI>

<logoffURI>/Logoff.do</logoffURI>
<authScheme>FORM</authScheme>
<loginField>login</loginField>

<passwordField>password</passwordField>
<goToLastAccessDeniedUriOnSuccess>true</goToLastAccessDeniedUriOnSuccess>
</configuration>
this configuration file specific to a web application is used to define the URI used when to follow jGuard Access
control decisions. The location of this file is specified in theweb.xml, especially in the AccessFilterdeclaration in
a configurationLocation parameter.
the AccessDenied URI is not defined in jGuardFilter.xml file, because it is already handled by the underlying protocol
;HTTP maps it to the status code 401. To use your customized accessDenied page, maps the error code in the web.xml
file of your webapp to its path.
3.4.1.2. jGuardAuthentication.xml
 the authentication scope
 the AuthenticationManager implementation
 the loginmodules involved in the authentication process with their options and JAAS keywords (required,
optional, and so on...)

538 | P a g e
3.4.1.3. jGuardAuthorization.xml
 authorization scope
 AuthorizationManager implementation
Chapter 4. java authentication
Table of Contents
4.1. Overall Authentication part
4.2. AuthenticationManager
4.2.1. description
4.2.2. configuration
4.2.3. implementations
4.3. JAAS Authentication process
4.3.1. javax.security.auth.login.LoginContext
4.3.2. javax.security.auth.callback.CallbackHandler
4.3.3. loginModules
4.3.4. javax.security.auth.login.Configuration
4.3.5. javax.security.auth.Subject
4.3.6. java.security.Principal
4.3.7. Dynamic role definition
4.4. password encryption
4.4.1. principle
4.4.2. supported algorithms
4.4.3. salted passwords
4.1. Overall Authentication part
Authentication part is composed of the Authentication process, which is involved when user is not authenticated, and
AuthenticationManager, which manage users and roles.they both share the same Authentication store.
Figure 4.1. Authentication part in jGuard

539 | P a g e
4.2. AuthenticationManager
4.2.1. description
AuthenticationManager implementations aims to do Create, Read, Update, Delete (CRUD) operations on users and
roles of the application. These Users and roles are present in the datasource authentication. This datasource
(database, XML and so on..), is also the same one used for the authentication process which
involveLoginContext, Configuration and LoginModules.
if the user does not tries to authenticate, jGuard automatically authenticates you as the 'guest' user. it's not a security
issue, but a design choice. but to fulfills your security requirements, you can configure that guest (unauthenticated
users), hasn't got access to your protected pages. how to do it? => configure the 'guest' role with no permissions. the
guest user will only have access to login page and access denied page(access is always grant to these resources).
4.2.2. configuration
Authentication configuration in jGuard, is done via the jGuardAuthentication.xml file.
goals of this configuration file is to:
 define the authentication scope

540 | P a g e
 define the AuthenticationManager implementation
 define the loginmodules involved in the authentication process with their options and JAAS keywords
(required, optional, and so on...)
4.2.3. implementations
4.2.3.1. XMLAuthenticationManager
4.2.3.1.1. description
This AuthenticationManager implementation permits to persist in a XML file all the auithentication informations of
your application.
4.2.3.1.2. parameters
 debug
This optional parameter, when set to true, activate the debug mode (provide more logs to detect easily
misconfiguration).
 authenticationXmlFileLocation
a relative path from the webapp, of the jGuardUsersPrincipals.xml file.
4.2.3.1.3. usual configuration in the jGuardConfiguration.xml file
....
....
<authenticationManager>net.sf.jguard.authentication.XmlAuthenticationManager</authenticationManag
er>
<authenticationManagerOptions>
<option>
<name>authenticationXmlFileLocation</name>
<value>WEB-INF/conf/jGuard/jGuardUsersPrincipals.xml</value>
</option>
</authenticationManagerOptions>
....
....
4.2.3.2. HibernateAuthenticationManager
The JdbcAuthenticationManager has been replaced by the HibernateAuthenticationManager for a better flexibility. A
further JPAAuthenticationManager, ORM agnostic AuthenticationManager implementation, can be another
suitable solution provided in a future release.
4.2.3.2.1. description
This AuthenticationManager implementation permits to persist in a database all the authentication informations of
your application.HIerbnaetAuthenticationManager needs to use a SessionFactory instance; here are the ways
supported to grab the sessionFactory

541 | P a g e
 hibernate.cfg.xml
Hibernate can build and use a sessionFactory by reading an Hibernate.cfg.xml config file present on the
classPath.
4.2.3.2.2. parameters
 authenticationXmlFileLocation
WEB-INF/conf/jGuard/jGuardUsersPrincipals.xml for example . This parameter permits to import some data
when your database is empty
4.2.3.2.3. configuration
....
....
<authenticationManager>net.sf.jguard.ext.authentication.manager.HibernateAuthenticationManager</a
uthenticationManager>
<authenticationManagerOptions>
<option>
<name>authenticationXmlFileLocation</name>
<value>WEB-INF/conf/jGuard/jGuardUsersPrincipals.xml</value>
</option>
</authenticationManagerOptions>
....
....
* you have to configure the associated HibernateLoginModule.
4.2.3.2.4. ER Diagram
Figure 4.2. authentication ER diagram

542 | P a g e
4.3. JAAS Authentication process
Authentication process is standardized into java through the JAAS api. It involves the LoginContext class, a
callbackHandler implementation, a Configuration instance, and some loginModules. jGuard provides
4.3.1. javax.security.auth.login.LoginContext
This class is the main entry point to the Authentication Process. it defines :
 which Subject (user) authenticate
 through which way (CallbackHandler)
 for which application
 with which authentication technologies (LoginModules)
 in which mechanism (Configuration)
This class provides multiple constructors which permits to build a convenient LoginContext class.
Authentication is done during the login method, which return an authenticatedSubject, or
a LoginException. when the user quit the application, the logout method should to be called.
in webapps, jGuard provides some high-level classes to reduce your work, and simplify the use of JAAS like
the AccessFilter servlet filter.
4.3.2. javax.security.auth.callback.CallbackHandler
this class handle the way to grab informations contained into information from a protocol, to fill callbacks (used by
loginmodules) to authenticate the user. So, LoginModules can use the same callbacks but with different
CallbackHandler depending on the situation. jGuard provides different callbackHandler
like JMXCallbackHandler, SwingCallbackHandler ,and HttpServletCallbackHandler.

Java secure development part 3

Java secure development part 3

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Viewers also liked

Viewers also liked (20)

Similar to Java secure development part 3

Similar to Java secure development part 3 (20)

More from Rafel Ivgi

More from Rafel Ivgi (14)

Recently uploaded

Recently uploaded (20)

Java secure development part 3