Securing OFBiz Application

Apache OFBiz is a popular open source ERP application. It’s a generic solution and can be used to automate any business process. To learn more on Apache OFBiz please read my earlier post and read here the developer guide.

In this article we are going to cover security part of the Apache OFBiz and securing OFBiz application is important for your production instance. OFBiz is distributed with a minimum of security features turned on. This is intentional to facilitate ease of initial software evaluation, customization, and testing. It is highly recommended that, at a minimum, you consider changing the default HyperText Transfer Protocol (HTTP) and HyperText Transfer Protocol Secure (HTTPS) communications ports and disabling demonstration login accounts before you go to Production.

We will go through each of these process in detail and step by step guide. So lets get started!

Securing communications ports

OFBiz depends heavily on the underlying TCP/IP networking stack, as well as the embedded Catalina/Tomcat servlet container. For example, the Catalina servlet container provides all the basic HTTP and HTTPS connection handling on the default IP ports of 8080 and 8443 respectively. Ports 8080 and 8443 by convention do not require any special usage privileges on the hosting system. This means that any non-privileged user may startup an OFBiz instance from the install directory.

Port 80 is used for non-secure connections while port 443 is used for secure, HTTPS-based communications. To run a web server on IP ports 80 and 443 often requires special privileges, sometimes called “root” or “superuser”, on the host server that is why when OFBiz is configured to run on these ports, it is considered by some to be more secure.

Also we need to secure ports 9990 and 9991, which are used to access the BeanShell interpreter through the TELNET protocol. You may either disable these ports or protect them using an external firewall.

Communication ports 80 and 443 may be set up by the following steps:

1. To change the HTTP/HTTPS ports, open the following file: ~framework/base/config/ofbiz-containers.xml

2. To change the default HTTP port from 8080 to 80, first locate the http-connector property. Within the http-connector specification, find the port property. Edit this property value as shown:

<property name="http-connector" value="connector">
 <!--Note property declarations removed. See file for details.-->
 <property name="port" value="80"/>
 <!--Note property declarations removed. See file for details.-->
</property>

3. To change the default HTTPS port from 8443 to 443, first locate the httpsconnector property. Within the https-connector specification, find the port property. Edit this property value as shown:

<property name="https-connector" value="connector">
 <!--Note property declarations removed. See file for details.-->
 <property name="port" value="443"/>
 <!--Note property declarations removed. See file for details.-->
</property>

4. To change or disable the default BeanShell ports, locate the beanshellcontainer property. To disable these ports, wrap the entire container definition in XML comments (). To change the ports, edit the property values as shown:

<container name="beanshell-container"
 class="org.ofbiz.base.container.BeanShellContainer">
 <property name="telnet-port" value="9911"/>
 <property name="app-name" value="OFBiz"/>
</container>

5. Save and close the file.

6. Restart OFBiz to make IP port configuration changes effective.

If you change servlet container HTTP/HTTPS settings, you probably will want to change the following settings within the ~framework/webapp/config/url.properties file. These settings are used internally by OFBiz to support automatic URL conversions. These settings are not passed to the servlet container:

• port.https.enabled=Y
• port.https=443
• port.http=80

Disabling demonstration user accounts

OFBiz comes with demonstrations for many of the ERP applications that make up the project. These demos are purposely distributed with privileged user login accounts enabled to showcase role base permission checking.

Before moving an OFBiz instance into production, at a minimum these demonstration privileged accounts should be disabled:

• flexadmin
• bizadmin
• demoadmin
• ltadmin
• supplier

To disable demonstration user accounts, follow these steps:

1. Log in into the Party Manager application (https://localhost:8443/partymgr) using the default username “admin” and password “ofbiz“.
2. Bring up the profile of the account you wish to disable by first locating the account using the Find Parties on Party Manager web page as shown here:
3. Under the User Name(s) section of the account on the Profile web page, click the Edit button to bring up the profile’s HTML form to Update UserLogin Security Settings as shown here:
4. Change the Enabled drop-down select box to N.
5. Add the Disabled Date Time using the calendar icon. If no disable time is selected, the current time will automatically be inserted in this field. Entering a value in this field allows you to select future dates for disabling.
6. Hit the Save button to make the change immediately effective.
7. Perform this set of tasks for every account that requires disabling.

Protecting OFBiz web pages

A user need only log in one time per session as OFBiz will check each request for a protected web page against a requesting visitor’s login status. If the requestor is already logged in, they will not be asked to login again. If the visitor is not logged in, they will be presented with an HTML login form.

Any web page may be set to require user authentication by way of the OFBiz login process by setting the corresponding request-map entry in the controller.xml file.

Identify the web application and the web page, OFBiz Service, or OFBiz Event that requires user authentication.

You can protect your web pages by following these steps:

1. Open the appropriate controller.xml file containing the request-map entry for the web page to protect.

2. Edit the request-map entry for the URI to be protected by setting the security element’s auth attribute to true. For example, the following request-map has both the authorization and encryption (https) attributes for the authview request-map set to true:

<request-map uri="authview">
 <security https="true" auth="true" />
 <response name="success" type="view" value="main" />
</request-map>

3. That is all you need to do to force a user to log in before accessing your web page. Note: there is no need to restart OFBiz. All controller.xml file changes are immediate.

Securing User Accounts

Global user profile security defaults are set in the following properties file: ~framework/security/config/security.properties Global options include:

• The minimum password length. Out-of-the-box, this value is five consecutive characters. Blank (” “) characters are not permitted in passwords.
• The number of failed attempts after which the user’s account will be disabled. This number defaults to three.
• The length of time to disable a user’s account should they fail to log in after the consecutive login attempt value. After this elapsed time, the user’s account will automatically be re-enabled and they may attempt to log in again.
• The encryption algorithm to use to encrypt passwords. The default is the one-way, internal SHA encryption algorithm.

Protecting applications using security groups

Security groups allow for fine-grain permission checking (Authorization), on a user-by-user basis, across an entire OFBiz web application (“webapp”). If you have webapps needing protection based on a user’s permissions that is, a user’s authorization to perform various business processing tasks and not just login authentication, then using security groups is the answer.

To protect an OFBiz webapp using security groups, proceed as described here:

1. In the ofbiz-component.xml file for the component containing the webapp to be secured, add one or more security groups using the base-permission attribute. To add multiple security groups, separate each group name with a comma (“,”). In the following example, we configure the partyowner security group association for the myapp webapp

2. In the controller.xml file within the myapp webapp, set the corresponding request-map entry security element’s auth attribute to true as shown here. This will force user login when requests for the web page are made.

3. Restart OFBiz and test coverage by trying to access a protected web page. Observe that you may be able to log in, but that you will be denied access to the webapp if the user login used is not a member of the appropriate security group(s).

4. Associate one or more users with the configured security group. A security group must also be associated with each user that you wish to authorize access to your protected web application. To associate one or more security groups with a user, you may use the security group’s Add UserLogin to Security Group form by selecting the User Logins tab as shown here:

Security groups may be used to apply fine-grain authorization or permission enforcement checks to individual web pages and portions of a web page within a protected web application. Using the following diagram, security group processing may be described as follows:

When a visitor makes a request for an OFBiz web page-

• The Controller Servlet (1) checks to see if the request-map security element’s auth attribute is set to true for the web page.
• If it is, the visitor is presented a Login form(2).
• After successful login, OFBiz checks to see if the webapp is configured to require further access mediation based on Security Groups (3).
• If there are no security groups configured for a webapp, the visitor now an OFBiz user is allowed access to the web page.
• If the webapp has one or more security group(s) configured, OFBiz checks to see if the user is a member of all configured groups.
• If not, the user is allowed to log in but is denied access to the web page and any protected web page(s) within the protected webapp.
• If the user is a member of all the configured security group(s), the user is assigned the appropriate Security Permissions (4) and allowed to continue (5) to the protected web page as shown in the previous diagram.

Once a user gains access to a webapp protected by security groups, they are permitted or denied use of OFBiz resources accessed through the web page, based on Security Permissions. Out-of-the-box, there are five security permissions that may be applied to mediate access to OFBiz resources.

Security groups and security permissions are an extremely flexible tool that may be used as needed to protect any OFBiz web application. In the following example, we will see how to apply two new security groups to the myapp web application:

The partyowner security groups is not part of the OFBiz distribution, and must be created. To create a new security group, use the Party Manager application as shown here:

1. Log in to the Party Manager application.
2. Select the Security tab.
3. Select the New Security Group tab.
4. Enter the name of the new security group and any description, and submit the HTML form. That is all you need do to create a new security group.

Security groups are like containers that hold one or more security permission(s). To associate one or more security permissions to a security group, for example, the “partyowner” security group created earlier, use the Party Manager application as shown here:

1. Edit the “partyowner” security group by selecting it from the list of security groups displayed on the Party Manager application’s SecurityGroups List as shown here:

2. Selection of the security group on the SecurityGroups List web page will bring up the Edit Security Group form for this security group. Select the Permissions tab to bring up the Edit Security Group Permissions form.

3. From the Add Permissions (from list) to SecurityGroup form select an existing security permission from the drop-down select box provided and hit the Add button. Continue adding as many security permissions as desired

Adding or changing SSL certificates

Secure Sockets Layer (SSL) is the protocol used by OFBiz to provide secure communications between browser clients and OFBiz webapps. Through SSL, secure communication sessions are enabled by using public and private keys to encrypt and decrypt messages on a user-byuser basis. Because the certificate containing the public key is used to identify the OFBiz server as a trusted source, most deployed OFBiz instances replace the out-of-the-box default public key certificate (provided primarily as a convenience) with one that has been signed and therefore authenticated by a third-party called a Certificate Authority (CA).

To create signed certificates, proceed as follows:

1. Since the SSL public key is derived from the private one, you must create the private key first and then use that key to create the public key. If you are using KeyTool, you can create the public key, private key, and the special file needed to store your keys and certificates, called the keystore, with the following command:

keytool -genkey -keyalg RSA -alias server -keystore mykeystore.jks 

You will be presented with a number of questions. Answer as appropriate for your server installation. The answers will be used to generate the certificate and key(s).

2. Create a Certificate Signing Request (CSR). A CSR is a document created by KeyTool that asks that the enclosed certificate be signed by a third-party. CSR can be created by giving this command:

keytool -certreq -alias server -keyalg RSA -file certreq.csr -keystore mykeystore.jks 

3. Send your CSR to a CA to be signed. CAs known to work with OFBiz include Verisign, Thawte, Comodo, GeoTrust, CACert.org, and FreeSSL. (See the OFBiz Wiki for details).

4. If instead you wish to self-sign your own certificate, run a command similar to the following. Answer the questions as appropriate for your server. This will create a self-signed certificate and automatically store it in the designated keystore.

keytool -selfcert -alias server -keyalg RSA -keystore mykeystore.jks

5. If you sent your certificate off to be signed, download your signed certificate from the CA.

6. Import your signed certificate containing your public key into the keystore using a KeyTool command similar to the following. If you self-signed your certificate, you will not need to perform this step as this was already done in step 4.

keytool -import -alias server -trustcacerts -file mysignedcert.cer -keystore mykeystore.jks

That is all you need to do to get a self-signed certificate into the keystore for OFBiz to use. If you have created a new keystore file as in the examples above, you need to tell OFBiz how to access this new repository.

To inform OFBiz where a keystore is located and the password to use when accessing this file, edit the ofbiz-containers.xml file as shown here. (Note: the keystorePass property value is the password you created for the keystore in step 1):

~framework/base/config/ofbiz-containers.xml

<property name="keystoreFile"
 value="framework/base/config/mykeystore.jks"/>
<property name="keystorePass" value="newpassword"/>
<!-- Note the keystore type needs to match the type used when
 creating the keystore -->
<property name="keystoreType" value="PKCS12" />

OFBiz single sign-on and the external login key

If an OFBiz user (whose session has not expired) stays within the processing domain of a single OFBiz webapp, they will not need to log in more than once. But, because of the nature of TCP/IP sessions and servlet container behavior, users moving between OFBiz webapps may be prompted to log in once for each OFBiz webapp they wish to access. Since any single OFBiz instance may support an unlimited number of webapps, certain users such as administrators may need to log in many times in the course of performing a single administrative task.

To help mitigate this situation, OFBiz provides a handy mechanism called the “External Login Key”. This feature enables logged in users to move between OFBiz web applications requiring authentication without having to log in more than one time.

Implementing the external login key mechanism requires two distinct activities. Both activities must be implemented for this to work:

1. Turn on external login key checking for each participating webapp within the appropriate controller.xml file.
2. Create a dynamic “external login key” request parameter and append it to the navigation link for each link that forwards a user to a participating OFBiz webapp web page.

To enable single sign-on, perform the following steps:

1. To turn on external login key checking for an OFBiz webapp, make sure the following Java class is configured within the preprocessor portion of the controller. xml file for that webapp. Conversely, to remove external login key checks, remove or comment out this line from the controller.xml file:

<preprocessor>
 <!-- Events to run on every request before security
 (chains exempt) -->
 <event name="checkExternalLoginKey" type="java"
 path="org.ofbiz.webapp.control.LoginWorker"
 invoke="checkExternalLoginKey"/>
</preprocessor>

2. Adding an external login key to an HTML location reference (HREF) within a FreeMarker template is easy. Use the externalLoginKey session attribute as shown here:

<a href=
”<@ofbizUrl>
/myofbizwebapp/control?externalLoginKey=${externalLoginKey!””}
</@ofbizUrl>”>
 Click Here
</a>

Conclusion

So, in this article we have covered in details how to secure your OFBiz Application using differenet ways. It is advised to follow all these for your Prodcution instance though it is not mandatory.

Let me know your thoughts/doubts/issues in the comments section

Tags: disable ofbiz demo user accountshow to create security groups in ofbizhow to secure ofbizprotect ofbiz using security groupsprotect ofbiz web pages