Professional Documents
Culture Documents
VERSION 24 Created on: 21 Oct, 2004 11:29 AM by unknownMigrationUser - Last Modified: 20 Jan, 2011 4:34 AM by unknownMigrationUser 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.
<?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: JBoss server.xml or jboss-service.xml versions 4.2.0 and higher 3.2.4 and 4.0.x 3.2.3 and lower <jboss install dir>/server/<configuration>/deploy/jboss-web.deployer/server.xml <jboss install dir>/server/<configuration>/deploy/jbossweb-tomcat50.sar/server.xml <jboss install dir>/server/<configuration>/deploy/jbossweb-tomcat41.sar/META-INF/jbossserver.xml
<filter> <filter-name>RemoteHostFilter</filter-name> <filterclass>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.
jboss-as-web/server/$PROFILE/conf/props/jmx-console-
users.properties.
b. Create a username = password pair.
username/password definition syntax. Do not use this for your user account. 2. Grant permissions to user a. Edit the file
jboss-as-web/server/$PROFILE/conf/props/jmx-console-
roles.properties.
b. Create an entry for the user of the form:
username=JBossAdmin,HttpInvoker
JBossAdmin Grant the user permission to access the JMX Console and Admin Console. HttpInvoker Grant the user permission to access the httpinvoker
Important
The authentication system applied to the JMX Console, Admin Console and Web Console does not block brute-force password attacks. It is recommended that in production environments, JBoss servers are protected by firewalls or reverse proxies that include measures to mitigate brute force attacks.
The HTTP Invoker is a service that provides HTTP and Remote Method Invocation (RMI) access for EJBs and the JNDI Naming service. Secure this service to prevent unauthorized access. Procedure 9.2. Secure the HTTP Invoker 1. Defining security constraints The
server/$PROFILE/deploy/http-invoker.sar/invoker.war/WEB-
2.
3.
Note
Binding the jmx-invoker to localhost is highly recommended for security, but makes it unavailable for use remotely. Edit
4.
service.xml:
5. <-- A pooled invoker bound to localhost -->
<mbean code="org.jboss.invocation.pooled.server.PooledInvoker" name="jboss:service=invoker,type=pooled,host=localhost"> <attribute name="NumAcceptThreads">1</attribute> <attribute name="MaxPoolSize">300</attribute> <attribute name="ClientMaxPoolSize">300</attribute> <attribute name="SocketTimeout">60000</attribute> <attribute name="ServerBindAddress">localhost</attribute> <attribute name="ServerBindPort">4443</attribute> <attribute name="ClientConnectAddress">localhost</attribute> <attribute name="ClientConnectPort">0</attribute> <attribute name="ClientRetryCount">1</attribute> <attribute name="EnableTcpNoDelay">false</attribute> <depends optional-attributename="TransactionManagerService">jboss:service=TransactionManager</depends>
18. In the
section, change
web-console-users.properties in jboss-as-
web/server/$PROFILE/deploy/management/console-mgr.sar/webconsole.war/WEB-INF/classes/.
b. Create a username = password pair.
definition syntax. Do not use this for your user account. 2. Grant permissions to user a. Edit the file
web-console-roles.properties in jboss-
as/server/$PROFILE/deploy/management/console-mgr.sar/webconsole.war/WEB-INF/classes/.
b.
c.
username=JBossAdmin,HttpInvoker
JBossAdmin
Important
The authentication system applied to the JMX Console, Admin Console and Web Console does not block brute-force password attacks. It is recommended that in production environments, JBoss servers are protected by firewalls or reverse proxies that include measures to mitigate brute force attacks.
jboss-as-web/server/$PROFILE/deploy/messaging/messaging-
jboss-beans.xml.
2. Change the
suckerPassword value.
3. <!-- A security constraint that restricts access to the HTML JMX console 4. to users with the role JBossAdmin. Edit the roles to what you want and 5. uncomment the WEB-INF/jbossweb.xml/security-domain element to enable 6. secured access to the HTML JMX console. 7. --> 8. <security-constraint> 9. <web-resource-collection> 10. <web-resource-name>HtmlAdaptor</webresource-name> 11. <description>An example security config that only allows users with the 12. role JBossAdmin to access the HTML JMX console web application 13. </description> 14. <url-pattern>/*</url-pattern> 15. <http-method>GET</http-method>
16. <http-method>POST</http-method> 17. </web-resource-collection> 18. <auth-constraint> 19. <role-name>JBossAdmin</role-name> 20. </auth-constraint> 21. </security-constraint> 22. <login-config> 23. <auth-method>BASIC</auth-method> 24. <realm-name>JBoss JMX Console</realmname> 25. </login-config> 26. <security-role> 27. <role-name>JBossAdmin</role-name> </security-role>
28. Edit the <JBOSS Install dir>/server/default/deploy/management/console-mgr.sar/webconsole.war/WEB-INF/classes/web-console-roles.properties and web-console-users.properties, and move those files to <JBOSS Install dir>/server/default/conf/props directory. and change the users and passwords to what you desire. The only change above should be to web-console-users.properties, i.e, set a password. 29. Edit <JBOSS Install dir>/server/default/deploy/management/console-mgr.sar/web-console.war/WEBINF/jboss-web.xml and uncomment the following security-domain block:<jboss-web>
<!-- Uncomment the security-domain to enable security. You will need to edit the htmladaptor login configuration to setup the login modules used to authentication users. --> <security-domain>java:/jaas/jmxconsole</security-domain> </jboss-web>
30. The security-domain value of web-console maps is declared in the login-config.xml JAAS configuration file which defines how authentication and authorization is done. edit <JBOSS Install dir>/server/default/conf/login-config.xml Change the path to the web-console-users.properties and the web-console-roles.properties as follows (add props/ to the front of the path)
A security constraint that restricts access to the HTML to users with the role JBossAdmin. Edit the roles to what uncomment the WEB-INF/jboss-web.xml/security-domain element secured access to the HTML JMX console.
<security-constraint> <web-resource-collection> <web-resource-name>HtmlAdaptor</webresource-name> <description>An example security config that only allows users with the role JBossAdmin to access the HTML JMX console web application </description> <url-pattern>/*</url-pattern> <http-method>GET</http-method> <http-method>POST</http-method> </web-resource-collection> <auth-constraint> <role-name>JBossAdmin</role-name> </auth-constraint> </security-constraint> <login-config> <auth-method>BASIC</auth-method> <realm-name>JBoss JMX Console</realmname> </login-config> <security-role> <role-name>JBossAdmin</role-name> </security-role>
3. Edit /server/default/conf/props/jmx-console-users.properties (version >=4.0.2) and /server/default/conf/props/jmx-console-roles.properties (version >=4.0.2) and change the users and passwords to what you desire. They will need the JBossAdmin role specified in the web.xml file to run the JMX Console. The only change above should be to jmx-console-users.properties, i.e, set a password.
4.
5. <jboss-web> 6. <!-- Uncomment the security-domain to enable security. You will 7. need to edit the htmladaptor login configuration to setup the 8. login modules used to authentication users. 9. --> 10. <security-domain>java:/jaas/jmxconsole</security-domain> </jboss-web>
Security on JBoss
16.1. Securing Applications
Filtering clients by source IP addresses Requiring authentication and authorization Data transport integrity and confidentiality (SSL) We will explore each one of these in turn
<Valve className="org.apache.catalina.valves.RemoteAdd rValve" allow="192.168.*,127.*" /> <Valve className="org.apache.catalina.valves.RemoteHos tValve" deny="spamhost.com" />
Configured through a Servlet Filter Simple implementation is provided by JBoss but servlet filters are Java EE AS-independent To limit client access through Tomcat, add a desired <Valve> in <Engine> or <Host> elements within${jboss.server.home.url}/deploy/jbossweb.sar/server.xml file Limiting per web application can be still done through Tomcat by creating a <Context> file${jboss.server.home.url}/deploy/<app>.war/WEB-INF/context.xml:
<Context>
<web-app ...> ... <filter> <filter-name>RemoteHostFilter</filter-name> <filterclass>org.jboss.remotehostfilter.RemoteHostFilter </filter-class> <init-param> <param-name>allow</param-name> <param-value>192.168.*,127.*</paramvalue> </init-param> </filter>
... </web-app>
A simple implementation of this filter can be found athttp://community.jboss.org/wiki/LimitAccessToCertainClients
<web-app ...> ... <security-constraint> <web-resource-collection> <web-resource-name>All Resources</webresource-name> <description>Protect all content</description>
<url-pattern>/*</url-pattern> </web-resource-collection>
<http-method>GET</http-method> </web-resource-collection>
If the <http-method> element is omitted, the default behavior is to apply the security constraint to all HTTP methods. The <auth-constraint> element indicates the user roles that should be permitted access to this resource collection. The <role-name> used here must either correspond to the <rolename> of one of the <security-role> elements defined for this web application (more on this soon), or be the specially reserved role-name "*" that is a compact syntax for indicating all roles in the web application. If no roles are defined, no user is allowed access to the portion of the web application described by the containing security-constraint. JBoss AS matches role names case sensitively when determining access. Adding login configuration:
<web-app ...>
... <security-constraint> <web-resource-collection> ... </web-resourcecollection> <auth-constraint> <role-name>Manager</role-name> </auth-constraint> <auth-constraint> <role-name>Administrator</role-name> </auth-constraint> </security-constraint> <login-config> ... </login-config> <security-role> <role-name>Manager</role-name> </security-role> <security-role> <role-name>Administrator</role-name> </security-role> ... </web-app>
16.5. Plain-Text Login Module
Already enabled by default
WEB-INF/classes/users.properties:
<policy> ... <application-policy name="other"> <authentication> <login-module code="org.jboss.security.auth.spi.UsersRolesLogin Module" flag="required" /> </authentication> </application-policy> ... </policy>
Note The properties files users.properties and roles.properties are loaded during
initialization of the context class loader. This means that these files can be placed into any Java EE deployment archive (e.g. WAR), the JBoss configuration directory, or any directory on the JBoss server or system classpath. Placing these files in the ${jboss.server.home.url}/deploy/<app>/WEB-INF/classes directory makes them unique to that specific web application. Moving them to ${jboss.server.config.url} directory makes them "global" to the entire JBoss AS instance. To change the names of these files, expand the <login-module> as follows:
<login-module code="org.jboss.security.auth.spi.UsersRolesLogin Module" flag="required"> <module-option name="usersProperties">myUsers.properties</module -option> <module-option name="rolesProperties">myRoles.properties</module -option></login-module>
16.6. Database Login Module
Fetches login info from a RDBMS Works with existing DB schemas Uses pooled database connections Scales well as the user population grows Does not require server or application restarts on info change Database Login Module depends on our ability to set up (and link to) a JBoss-managed DataSource (database connection pool).
16.6.1. MySQL Schema/DB Setup
term#> mysql/bin/mysql -u root -p mysql> CREATE DATABASE Authority; mysql> USE Authority; mysql> CREATE TABLE Users (Username VARCHAR(32) NOT NULL PRIMARY KEY,Password VARCHAR(32) NOT NULL); mysql> CREATE TABLE Roles (Username VARCHAR(32) NOT NULL,Rolename VARCHAR(32) NOT NULL,PRIMARY KEY (Username, Rolename)); mysql> GRANT SELECT ON Authority.* TO authority@localhost IDENTIFIED BY "authsecret";
It is important that the password field be at least 32 characters in order to accommodate MD5digest-based passwords (more on this later). You do not have to create a separate database, nor do you need separate tables, but we assume that we are starting from scratch. The default JBoss AS schema for User/Role information is as follows: Table Principals(PrincipalID text, Password text) Table Roles(PrincipalID text, Role text, RoleGroup text) You also do not need a auth-specific read-only database user, but we create one because it is a good practice. Populate the database. For example:
("john", "secret"); ("john", "MyRole"); ("bob", "abc123"); ("bob", "MyRole"); ("bob", "Manager"); ("mike", "passwd"); ("mike", "Manager"); ("mike", "Admin");
Create deploy/authority-ds.xml:
Add to conf/login-config.xml:
<application-policy name="MyPolicy"> <authentication> <login-module flag="required" code="org.jboss.security.auth.spi.DatabaseServerL oginModule"> <module-option name="dsJndiName">java:/AuthorityDB</moduleoption> <module-option name="principalsQuery">SELECT Password FROM Users WHERE Username=?</module-option> <module-option name="rolesQuery">SELECT Rolename, "Roles" FROM Roles WHERE Username=?</module-option> </login-module> </authentication></application-policy>
Application policy name declares a new policy. We will reference this name in each [web] application that wishes to use it. The required flag means that the login module is required to succeed. If it succeeds or fails, authentication still continues to proceed down the LoginModule list Other options are: requisite, sufficient, and optional
Module option dsJndiName: Defines the JNDI name of the RDBMS DataSource that defines logical users and roles tables Defaults to java:/DefaultDS Module option principalsQuery: Defines a prepared SQL statement that queries the password of a given username Defaults to select Password from Principals where PrincipalID=? Module option rolesQuery: Defines a prepared SQL statement that queries role names (and groups) of a given username The default group name is Roles (hard-coded). Defaults to select Role, RoleGroup
Add to WEB-INF/jboss-web.xml:
<jboss-web> <security-domain>java:/jaas/MyPolicy</securitydomain></jboss-web>
Default security domain is other, which authenticates against the properties files Security domains declared in conf/login-config.xml are relative to java:/jaas/ JNDI context
16.6.5. Securing Passwords
john=5ebe2294ecd0e0f08eab7690d2a6ee69 bob=e99a18c428cb38d5f260853678922e03
mike=76a2173be6393254e72ffa4d6df1030a
16.7. FORM-based Login
Session-based Allows Logout - session.invalidate() Automatically expires when the session expires More efficient and secure - single authentication Fully customizable Control the layout of the login page Control the layout of the error page Provide links to "user registration" or "recover password" actions Support for FORM-based login is part of the Java EE specification, and like the rest of JAASbased security, it is independent of the application server With the FORM-based login, the server forces the users to login via an HTML form when it detects the users session is not authenticated This is accomplished by forwarding the users' requests to the login page In case of authentication failures, users are sent to the login error page
16.7.1. Login.jsp Form Page
<html> <head><title>Login Form</title></head> <body> <h1>Login Form</h1> <form action="j_security_check" method="post"> Username: <input type="text" name="j_username"/><br/> Password: <input type="password" name="j_password"/><br/> <input type="submit" value="Login" />
<html> <head><title>Login Error</title></head> <body> <h1>Authentication Error</h1> <p style="color: red"> Invalid username and/or password. </p> <p><a href="Login.jsp">Try again?</a></p> </body> </html>
This page is only shown if user enters invalid username and/or password. Authorization errors (user not in required role) are handled separately.
16.7.3. Update Login Configuration
Authorization failures are expressed by HTTP 403 status codes Use <error-page> element to configure HTTP 403 handler in web.xml:
keytool -genkey -keystore conf/ssl.ks -storepass secret -alias tomcat -keyalg RSA -keypass secret What is your first and last name? [Unknown]: localhost What is the name of your organizational unit? [Unknown]: IT What is the name of your organization? [Unknown]: Secure Org What is the name of your City or Locality? [Unknown]: San Francisco What is the name of your State or Province? [Unknown]: CA What is the two-letter country code for this unit? [Unknown]: US Is CN=localhost, OU=IT, O=Secure Org, L=San Francisco, ST=CA, C=US correct? [no]: yes
Refer to http://tomcat.apache.org/tomcat-6.0-doc/ssl-howto.html for more info.
... 14:41:01,002 INFO Coyote HTTP/1.1 on 14:41:02,195 INFO Coyote HTTP/1.1 on ...
When you point your browser to http://localhost:8443/status you will get a browser warning telling you that the SSL certificate has not been signed by a certification authority that you trust. This is expected, since we signed our own certificate. Skipping the warning should show the SSLprotected page (pad-lock).
Add support for SSL Require SSL in one or more of the applications To filter clients by their source IP see Section 16.2, Filtering Clients by Source For a virtual host, add <Valve> to <Host> in Tomcats server.xml For a web application, add <Valve> to <Context> in applications WEB-INF/context.xml file To implement authentication and authorization (Section 16.3, Authentication & Authorization): Plain text (Section 16.5, Plain-Text Login Module) Database (Section 16.6, Database Login Module) Securing passwords (Section 16.6.5, Securing Passwords) To add support for SSL (Section 16.8, Configuring JBoss AS for SSL): Require SSL (Section 16.12, Requiring SSL in Apps)
JBM_USER and JBM_ROLE tables have been created by the JMSUserManager component
when we have set up the persistence to use MySQL. First, declare a new security domain in the conf/login-config.xml file in your server configuration set folder:
<policy> ... <application-policy name="JMSRealm"> <authentication> <login-module code="org.jboss.security.auth.spi.DatabaseServerLog inModule" flag="required"> <module-option name="dsJndiName">java:/MySqlDS</module-option> <module-option name="principalsQuery"> SELECT passwd FROM jbm_user WHERE user_id=? </module-option>
<module-option name="rolesQuery"> SELECT role_id, 'Roles' FROM jbm_role WHERE user_id=? </module-option> </login-module> </authentication> </application-policy> ... </policy>
Then, add the security domain you just created to the configuration of JBM security store that you can find in the deploy/messaging/messaging-jboss-beans.xml:
<bean name="SecurityStore" class="org.jboss.jms.server.jbosssx.JBossASSecurity MetadataStore"> ... <property name="securityDomain">JMSRealm</property> <!--> ... </bean>
This is where you need to specify which security domain to use Create now a secured Topic:
<mbean code="org.jboss.jms.server.destination.TopicService " name="jboss.messaging.destination:service=Topic,nam e=securedTopic" xmbean-dd="xmdesc/Topic-xmbean.xml"> <depends optional-attributename="ServerPeer">jboss.messaging:service=ServerPee r</depends> <depends>jboss.messaging:service=PostOffice</depend s> <!---> <attribute name="SecurityConfig"> <security> <role name="publisher" read="true" write="true"/>
connection = cf.createConnection("dynsub","dynsub");
16.15. Securing JBoss AS
Running JBoss AS with low privileges File system security Securing console applications/tools Restricting remote shutdown Protecting twiddle tool Securing other JBoss AS services Running with Java Security Manager Running behind a firewall We will examine each of these in turn.
${jboss.home_url}
JBoss user must have write access to data/, log/, tmp/, and work/ directories under ${jboss.server.home.url} (under default configuration set)
Depending on the deployed apps' requirements, JBoss user may need write access to parts of${jboss.server.home.url}/deploy dir Other users should in particular have no access to ${jboss.server.config.url} and${jboss.server.home.url}/deploy directories as these often contain sensitive information like database or SSL-certificate passwords. Although supported by NTFS, file system security is often not employed to secure system services like JBoss AS under Windows.
<!-- Uncomment to require authenticated users <descriptors> <interceptors> <interceptor code="org.jboss.jmx.connector.invoker.Authenticatio nInterceptor" securityDomain="java:/jaas/jmxconsole"/> </interceptors> </descriptors> -->
By default, the security domain java:/jaas/jmx-console authenticates against filedefault/conf/props/jmx-console-users.propertiesThis file is in <user>=<password> format. Roles are not important. To specify the username and password for twiddle or shutdown scripts, use -u <user> -p
Uncomment <security-constraint> in web.xml and <security-domain> in jbossweb.xml under${jboss.server.home.url}/deploy/jmx-console.war/WEB-INF/ Set or change the admin password in ${jboss.server.config.url}/props/jmx-
console-users.properties
Requiring authentication and authorization for web-console: Uncomment <security-constraint> in web.xml and <security-domain> in jbossweb.xml under
${jboss.server.home.url}/deploy/management/web-console.war/WEB-INF
(JBoss version<4.0.2) OR
${jboss.server.home.url}/deploy/management/console-mgr.sar/webconsole.war/WEB-INF/ (JBoss version>=4.0.2) Update ${jboss.server.config.url}/login-config.xml such that<applicationpolicy name="web-console"> loads usersProperties fromprops/web-consoleusers.properties and rolesProperties fromprops/web-consoleroles.properties
Add a user that belong to JBossAdmin role in the two properties files Restart JBoss for the changes to take effect.
};
To figure out which permissions you need, you can debug the security manager. Run java -
Djava.security.debug=help to see a list of debugging options. Using Djava.security.debug=all in JAVA_OPTS is the most verbose (probably too verbose), whereas setting java.security.debug to access,failure may be sufficient to determine a
suitable security policy.
Additional listening ports in all configuration: 1100 TCP HA Naming Service 1101 TCP HA Naming Service RMI 1102 UDP HA Naming Service AutoDiscovery 1161 UDP Snmp Agent Service 1162 UDP Trapd Service 3528 TCP IIOP Invoker 4447 TCP JRMPInvoker HA 45566 UDP Cluster Partition
This document (3024921) is provided subject to the disclaimer at the end of this document.
Environment
JBoss Application Server versions 5.0 JBoss Application Server versions 4.0.1 SP1 JBoss Application Server versions 4.0.2 SP1 JBoss Application Server versions 4.0.3 SP1 JBoss Application Server versions 4.0.5 Novell Identity Manager UserApplication 3.0 Novell Identity Manager UserApplication 3.0.1 SP1 Novell Identity Manager UserApplication 3.5.1 Novell Identity Manager UserApplication 3.6.0 Novell Identity Manager UserApplication/RBPM 3.6.1 Novell Identity Manager UserApplication/RBPM 3.7 Novell Identity Manager UserApplication/RBPM 4.0.1
Situation
Symantec discovered a flaw in the DeploymentFileRepository class of the JBoss Application Server. A remote attacker who is able to access the console manager could read or write to files with the permissions of the JBoss AS user. This could potentially lead to arbitrary code execution as the JBoss AS user. (CVE-2006-5750) Please note that the JBoss AS console manager should always be secured prior to deployment, as directed in the JBoss Application Server Guide. By default, the JBoss AS installer gives users the ability to password protect the console manager, limiting an attack using this vulnerability to authorised users. These steps can also be performed manually.
Statement Regarding Security Threat to JBoss Application Server: Red Hat has become aware of a worm currently affecting unpatched or unsecured servers running JBoss Application Server and products based on it.
New Update as of 10/22/2011 Jboss announced a new
The quickest and easiest approach to correct this security vulnerability is to; 1. Remove the offending service 2. Secure the JBoss JMX and Web Consoles However, we strongly feel the best approach is to secure JBoss using the following optional procedures; - secure jmx-console and web-console authentication via SSL - secure your Web Application in Jboss Application Server - use a one-way hash to protect the administrative password property file - secure the invokers To remove the offending service use the following steps; 1. Undeploy completely the web-console application by removing the directory deploy/management from the 'default' and 'all' configurations or
Secure the Jmx and Web Console's 1. Secure the JMX Console using a username/password file Locate the jmx-console.war directory. Normally found in server/default/deploy in your JBOSS_HOME directory. edit the WEB-INF/web.xml, uncomment the security-constraint block edit the WEB-INF/jmx-console-users.properties or server/default/conf/props/jmx-consoleusers.properties (version>=4.0.2) and WEB-INF/jmx-console- roles.properties or server/default/conf/props/jmx-console-roles.properties (version>=4.0.2) and change the users and passwords to what you desire. Please note: They will need the JBossAdmin role specified in the web.xml file to run the JMX Console. edit the WEB-INF/jboss-web.xml, uncomment the security-domain block. The security-domain value of jmx-console maps is declared in the login-config.xml JAAS configuration file which defines how authentication and authorization is done. 2. Secure the JMX Console using your own JAAS domain edit the WEB-INF/web.xml as above, uncommenting the security-constraint block. Change the role-name value to be the role in your domain that can access the console edit the WEB-INF/jboss-web.xml as in step1, set the security domain to be the name of your security domain. For example, if your login-config.xml has an application-policy whose name is MyDomain then your JAAS domain java:/jaas/MyDomain redeploy the application 3. Secure the web console In the deploy directory, locate management/web-console.war and make the same changes as above to the WEB-INF/web.xml, WEB-INF/jboss-web.xml and the users/groups properties file. The default JAAS domain used by the web-console is java:/jaas/web-console and is defined in loginconfig.xml in the conf directory. You can use a custom JAAS domain or customize the existing domain in the same way as with the JMX console. Typically you would just use the same domain (java:/jaas/jmx-console) as the jmx-console so that you have a single user/role mapping to configure.
Update for 4.0.2 The jmx-console-roles.properties and jmx-console-users.properties files have been moved to server\default\conf\props. The web console,is unpacked already in the default server configuration as deploy/management/console-mgr.sar/web-console.war. Edit the WEB-INF/web.xml and jbossweb.xml files as per securing the JMX console.
A quicker method to secure the Web and JMX console is the following: 1. Navigate to JBOSS_HOME/server/default/deploy/jmx-console.war/WEB-INF/web.xml and uncomment the security-constraint block, add a block after the end of the block. Example: BASIC JMXConsole
2. Navigate to JBOSS_HOME/server/default/deploy/jmx-console.war/WEB-INF/jboss-web.xml
and uncomment the security-domain block 3. Navigate to $JBOSS_HOME/server/default/conf/props/jmx-console-users.propertiesand change the password for admin 4. Navigate to JBOSS_HOME/server/default/deploy/management/console-mgr.sar/webconsole.war/WEB-INF/web.xml and uncomment the security-constraint block 5. Navigate to JBOSS_HOME/server/default/deploy/management/console-mgr.sar/webconsole.war/WEB-INF/jboss-web.xml and uncomment the security-domain block 6. Navigate to JBOSS_HOME/server/default/conf/login-config.xml and change the path to the web-console-users.properties and the web-console-roles.properties as follows (add props/ to the front of the path) props/web-console-users.properties props/web-console-roles.properties 7. Navigate to JBOSS_HOME/server/default/deploy/management/console-mgr.sar/webconsole.war/WEB-INF/classes/web-console-*.properties and JBOSS_HOME/server/default/conf/props edit as needed 8. Navigate to JBOSS_HOME/server/default/conf/props/jmx-console-roles.properties and JBOSS_HOME/server/default/conf/props/web-console-roles.properties and edit as needed 9. Restart jboss How to secure the JMX-console and Web-console authentication via SSL These steps will redirect jboss admin pages to https://localhost:8443 1. You must first enable http authenication as outlined in the sections previously outlined above 2. Navigate to JBOSS_HOME/server/default/deploy/management/console-mgr.sar/webconsole.war/WEB-INF/web.xml, include the following just before end of tag security-constraint ... CONFIDENTIAL 3. Navigate to JBOSS_HOME/server/default/deploy/jmx-console.war/WEB-INF/web.xml,include the following just before end of tag security-constraint ... CONFIDENTIAL 4. Create a keystore and supply a secure password. (for information on creating a keystore please see TID#3103136 How to install a signed certificate into Jboss for the IDM3 User Application, http://www.novell.com/support/search.do?cmd=displayKC&docType=kc&externalId=3103136 &sliceId=SAL_Public&dialogID=24642412&stateId=0%200%2024646267 5. Enable SSL in JBoss locate jbossweb-tomcat55.sar file under \jboss\server\YourJBossServer\deploy. In it, find server.xml and open that file in a text editor. Enable SSL by uncommenting "SSL/TLS Connector" or adding the following section if it is not there: maxThreads="100" strategy="ms" maxHttpHeaderSize="8192" emptySessionPath="true" scheme="https" secure="true" clientAuth="false" keystoreFile="${jboss.server.home.dir}/spitfire/conf/jboss.jks" keystorePass="changeit" sslProtocol ="TLS" /> **Note 1: Remember to point "keystoreFile" to the keystore you created. example: ${jboss.server.home.dir}/conf/server.keystore **Note 2: Remember to change the keystorePass="changeit" to your keystore password 6. Restart your JBoss Server and test. When restarting the JBoss Server you should see the server running on 2 ports, your http port and your ssl port https:8443 Securing a Web Application in JBossAS Create a simple security domain for JBoss SX Open the ${jboss.dist}/server/${server.name}/conf/login-config.xml file This file sets up the configuration for the security domains available to applications running in the server. The file contains a few example domains you may want to look at for reference. JBoss SX uses JAAS for the infrastructure of the underlying security
JAAS uses a class called a "login module" to interact with a security store for authenticating credentials. This file basically hooks up a security domain to a JAAS login module. JBoss Application Server comes packed with the "UsersRolesLoginModule". The "UsersRolesLoginModule" allows you to specify user names, passwords and roles in a simple property file. Copy the "jmx-console" domain policy The "jmx-console" security domain policy contains the basics for configuring a UsersRolesLoginModule based security domain. <LOGIN-MODULE code="org.jboss.security.auth.spi.UsersRolesLoginModule" flag = "required"> <MODULE-OPTION name="usersProperties"> props/jmx-console-users.properties <MODULE-OPTION name="rolesProperties"> props/jmx-console-roles.properties copy this section to the bottom of the file edit the "name" attribute on the application-policy attribute to "my-web" edit the "userProperties" module-option text value to be"props/my-web-users.properties" edit the "roleProperties" module-option text value to be"props/my-web-roles.properties" save the login-config.xml file. In the ${jboss.dist}/server/conf/props directory, copy the jmx-console-users.properties into a new file called my-web-users.properties, copy the jmx-console-roles.properties into a new file called my-web-roles.properties. open "my-web-users.properties" file, notice that you will see a single entry like: "admin=admin" (The structure is "username=password"). When a user logs into the security domain, the login module will examine the properties data in this file for users. Add a new user, for example"tester=security", to the file under "admin=admin" Save file open the my-web-roles.properties file, notice an entry similar to the following:"admin=JBossAdmin,HttpInvoker". These entries define the roles a user has associated with their account at login. The structure is "username=Role1,Role2,..." the username is the user you wish to assign roles to,and the Roles entries are a comma separated list of roles to assign to that user. Add a new entry to this file, for example "tester=WebAppUser" on a new line below the"admin=....". Save file. Configure the web application for security by adding constraints to the web deployment descriptor. modify the web.xml in the WEB-INF directory of the web application you are securing to add in the following: All resources Protects all resources /*
WebAppUser
WebAppUser
Note:"security-constraint" is used to define what resources in the web application are protected. "url-pattern" element specifies the URL pattern to protect (example above protects _all_ resources in the web application) "auth-contraint" element specifies which roles have access to the protected resource (example just specifies one role) -This role name must match the name of the role you specified in"my-webroles.properties" file. "login-config" element specifies how authentication occurs with the web application. "auth-method" element specifies how the browser gets credentials from the user. -"BASIC", "DIGEST","FORM", and "CLIENT-CERT" are possible methods to retrieve data from the browser user. The example above uses"BASIC", but this method should not be used in a production environment unless you are using SSL/TLS "realm-name" element just specifies the authentication realm name that is given to the browser for authentication. Configure the jboss-web.xml file to point to the "my-web" application. edit the jboss-web.xml in the WEB-INF directory of the web application you are securing -add the following in the"jboss-web" element: java:/jaas/my-web This instructs JBoss Application Server to connect the web application to the "my-web" security domain we defined in the login-config.xml file earlier. Start the JBoss Application Server In a browser navigate to your application -you should be prompted for username and password. Enter the user and password we created earlier in our example we used "tester" for the username, and "security" for the password. If your set-up is correct, you will be allowed access to the web application. To test, close browser open and navigating back to your application. When prompted, enter no credentials, or "admin" with password: admin, you should not have access to the application Protecting the Administrator password property file You can also use a one-way hash for protecting the admin password property file. In the above section on"Securing a Web Application in JBoss AS we used the following configuration fragment:
props/jmx-console-users.properties props/jmx-console-roles.properties
To add the hash support, you need to add the following options to it: MD5 base64 Now in the usersProperties file, you no longer do user=pass. Instead, you do user=md5(pass). The user is responsible for generating the md5() value, either by themselves or using the following program (please notice that it relies on org.jboss.security.Util, which is in jbosssx.jar). import java.security.MessageDigest; import org.jboss.security.Util; class HashPassword { public static void main(String[] args) {
String password = args[0]; MessageDigest md = null; try { md = MessageDigest.getInstance("MD5"); } catch(Exception e) { e.printStackTrace(); } byte[] passwordBytes = password.getBytes(); byte[] hash = md.digest(passwordBytes); String passwordHash = Util.encodeBase64(hash); System.out.println("password hash:"+passwordHash); } } Securing the Invokers Enabling authentication to the RMIAdaptor service in JBossAS 4.0.x, edit jmx-invoker-service.xml in JBossAS 3.2.x, edit jmx-invoker-adaptor-server.sar/META-INF/jboss-service.xml and uncomment the descriptors section of the invoke operation: The detached invoker entry point invoke The method invocation context invocation org.jboss.invocation.Invocation java.lang.Object
securityDomain="java:/jaas/jmx-console"/> The value of the securityDomain attribute maps to the security domain name found in the conf/loginconfig.xml definitions the same way as the jboss.xml, jboss-web.xml security-domain elements. Enabling authorization to the RMIAdaptor service -An "AuthorizationInterceptor" is available in JBoss. The place the interceptor after the"AuthenticationInterceptor" configuration: * authorizingClass : Fully Qualified Name of a class that does the authorization and 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 the org.jboss.jmx.connector.invoker.RolesAuthorization, which looks for an hardcoded "JBossAdmin?" role in the authenticated subject. securityDomain="java:/jaas/jmx-console"/> authorizingClass="org.jboss.jmx.connector.invoker.RolesAuthorization"/> Starting with 4.0.4.GA, Jboss has an authorization delegate that looks for passwords from a properties file called as "jmxinvoker-roles.properties" in a jar file or can be in the conf directory. securityDomain="java:/jaas/jmx-console"/> authorizingClass="org.jboss.jmx.connector.invoker.ExternalizableRolesAuthorization"/> The format of the"jmxinvoker-roles.properties" file is: #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 1. try placing the security-service.xml in a SAR 2. create a folder named security.sar that has a subfolder named META-INF 3. move your security-service.xml to this folder and rename it to jboss-service.xml
4. Place the security.sar in the deploy-folder New Update as of 10/22/2011 additional information for locking down the Jboss Application Server Here is the link for locking down the different versions of the JBoss consoles: http://community.jboss.org/wiki/SecureTheJmxConsole