Securing NexJ applications

Before you deploy your NexJ application to a production environment, you should ensure that you have taken steps to secure the application.

Enabling data access security models

The NexJ application provides security models that enable you to restrict user access to data records.

The NexJ application provides the following security models:
• Hierarchical Access Model
• Coverage Access Model
• Group Security Model

Hierarchical Access Model

The Hierarchical Access Model is a security model that restricts user access to data records by organizational hierarchy. A user's position in the hierarchy determines which data they can access. The Hierarchical Access Model applies to contacts, companies, households, and to their related opportunities and activities. Your development team can enable the Hierarchical Access Model during deployment.

Info

A household is an entity that represents a group of contacts who belong to the same family.

Configure the Hierarchical Access Model to restrict access to contacts, companies, and households in the hierarchy for your users.

The following diagram shows an example of a hierarchy that is supported by the Hierarchical Access Model. Users that are assigned to the highest levels of the hierarchy will have the most access to data records.

The Hierarchical Access Model provides users with access to:

• Contacts, companies, and households in their hierarchy
• Opportunities associated with the contacts, companies, and households that they have access to through the hierarchy
• Activities associated with the contacts, companies, and households that they have access to through the hierarchy and activities that they have been assigned in the Assign To field

The following table shows examples of the data access provided by the Hierarchical Access Model for a sales representative, branch manager, and executive user.

Data access examples of using the Hierarchical Access Model

Info

Enabling the Hierarchical Access Model disables the Security tab for contacts, companies, households, and their related opportunities and activities in NexJ CRM. For other application subject areas, the Security tab will continue to be available.

Enabling the Hierarchical Access Model

You can choose to enable the Hierarchical Access Model in NexJ Studio.

To enable the Hierarchical Access Model:

1. In NexJ Studio, open the Deployment layer.
2. In the Environments tab, open the environment file for your deployment.
3. Select the Source tab, and in the <Environment> tag, add the hierarchySecurityEnabled="true" attribute, as shown in the following example:
   <Environment ... hierarchySecurityEnabled="true">
4. Click the Save button to save your changes to the environment.

The Hierarchical Access Model is enabled for your deployment. If your NexJ application is currently running, you must redeploy it for changes to take effect.

The system administrator will configure the Hierarchical Access Model by defining your organizational hierarchy and assigning users to the hierarchy in NexJ Admin Console.

Coverage Access Model

The Coverage Access Model restricts data access in NexJ Customer Relationship Management by coverage team. Users receive view and edit access to contacts, companies, households, and their corresponding opportunities and activities by being part of a coverage team. The Coverage Access Model is always enabled.

The Coverage Access Model provides users with access to:

• Contacts, companies, and households for which they are members of a coverage team
• Opportunities and activities associated with the contacts, companies, and households that they have access to through a coverage team

Group Security Model

The Group Security Model is a security model that enables users to apply public, group, and private view and edit security settings to contacts, events, leads and opportunities, call records, and activities. Subject areas include contacts, events, leads and opportunities, call records, and activities. The Group Security Model is provided with NexJ CRM.

Users can define the following view and edit security settings for subject areas:

Public
All users that can log in to NexJ CRM have access to the data record.

Group
Only selected user groups have access to the data record.

Private
The data record is available only to the current user who changed the security setting to private and to the following users:

• Record owners and coverage team members of a contact or opportunity
• Users specified in the Assign To field in an activity

Info

If you enable the Hierarchical Access Model then you disable the Security tab for contacts, companies, households and their related opportunities and activities, which are secured using the Hierarchical Access Model. For other application subject areas, the Security tab will continue to be available.

Customizing NexJ perimeter authentication

Perimeter authentication is a security architecture that is independent of an application container's security. Perimeter authentication enables a services-based architecture, where a deployment passes authentication tokens between components, and each perimeter-enabled component confirms security with a centralized authentication controller based on the NexJ single sign-on (SSO) model. Users in a perimeter-secured environment are not aware that they are using different models or servers.

To enable perimeter authentication, you must configure the environment files for each application to secure. Additionally, you must configure the timeout behavior for your deployment and add trusted URLs used to access your NexJ applications to a whitelist in the default relational database.

Configuring environments for NexJ perimeter authentication

To customize perimeter authentication for your NexJ applications, first ensure that the environment file for your NexJ applications are configured correctly.

To configure an environment file for NexJ perimeter authentication:

1. In NexJ Studio, navigate to the Deployment layer.
2. In the Environments tab, open the environment for your NexJ application.

3. In the Source tab, add a PKI key pair named nexjsa.

   

   Note

   You must name the key pair nexjsa for perimeter authentication to function correctly.

   Your source code for the key pair should be similar to the following:

   TEXT

   <PKIKeyPairs> 
      <PKIKeyPair keystore="<keystore>" name="nexjsa" password="text:<password>"/> 
   </PKIKeyPairs>

   
where <keystore> is the Base64-encoded PKI keystore in the PKCS #12 format, and <password> is the password
   for the nexjsa user.

4. In the SOA Connections tab, in the SOA Connections area, select nexj:sso:Authentication:1.0.

5. In the General tab, specify the following properties for the connection:
   Binding
   context
   Authentication
   perimeter

6. In the Properties subtab, click the Add button

   

   and create a property with the following parameters:
   Name
   system
   Value
   #t

7. In the Data Source Connections tab, in the Data Source Connections zone, select DefaultRelationalDatabase.
8. In the General tab, in the Data Sources zone, ensure that the sso:SSO data source is present. If sso:SSO is not present, do the following:
   1. In the Data Sources zone, click the Select button

      

      .
      The Select Data Sources dialog opens.
   2. In the list on the left side of the dialog, select sso:SSO, then click Add.
      The data source is added to the list on the right side of the dialog.
   3. Click OK.
      The Select Data Sources dialog closes.
9. Click the Save button

   

   to save your changes to the environment.

The environment is configured. Repeat this task for each environment to secure in your deployment.

Next you must configure the timeout behavior for your deployment.

Related links

Adding PKI keys to an environment file 

Configuring timeout behavior for NexJ perimeter authenitcation

Edit the single sign-on (SSO) security class for your deployment and specify the timeout behavior for your NexJ applications. The timeout behavior for a deployment determines when the system logs users out of NexJ applications. This helps to protect a user's account in the event that they forget to log out, or leave their computer unattended. For example, you can configure your deployment to log out users who are logged in for longer than a week, or are inactive for longer than 15 minutes.

To configure the timeout behavior for your NexJ applications:

1. In NexJ Studio, navigate to the Business Model layer.
2. In the Classes tab, open sso:SysSecurityContextConfig.

3. In the Attributes tab, set the following values:
   Recommended timeout values for perimeter authentication

   Attribute	Value	Description
   authenticationTimeout	10080	The amount of time, in minutes, that a user can remain logged in before the authentication token expires and the user is logged out.
   inactivityTimeout	0	The amount of time, in minutes, that a user can remain inactive before they are automatically logged out. Set to 0 to disable inactivity timeout.
   inactivityWarningTime	0	The amount of time, in minutes, before users receive a warning that their session will time out due to inactivity. The attribute in conjunction with inactivityTimeout. Set to 0 to disable inactivityWarningTimeout.

   To set the value for an attribute, in the Attributes zone, select the attribute. In the Value tab, enter the value in the Value field.

   

   Info

   The preceding values are the default recommended configuration for NexJ perimeter authentication. Specify values that meet the security needs of your deployment.

   
   4. Click the Save button

   

   to save your changes to the class.

The timeout behavior for your deployment is configured.

Next you must add trusted sites to a whitelist for your NexJ applications.

Configuring a whitelist for NexJ perimeter authentication

Add trusted sites to the whitelist in your NexJ application's default relational database. The whitelist restricts what sites NexJ applications can redirect users to after they log in or log out. After an application validates a user's credentials, it redirects requests only to sites in the whitelist. Adding trusted sites to the whitelist helps to prevent cross-site scripting (XSS) vulnerabilities.

Info

A whitelist is required for deployments where your NexJ applications are accessible on more than one web server URL.

To configure the whitelisfor NexJ perimeter authentication:

1. In your application's default relational database, add a record to the NJWhitelist table.
2. In the resource column, enter the fully-qualified domain of the server to add as a trusted site.
   Enter the domain using the following format:
   ^(http|https)://host.domain.name(:[^/]*)?(/.*)?
3. In the privilege column, enter SSOGoto.

The site is added to the whitelist. Repeat this task for each trusted site that users are redirected to by your NexJ applications.

Encrypting deployment files and passwords

Before you deploy your NexJ application to a production environment, you should help to secure it by encrypting your deployment files and passwords.

While you are developing your NexJ application, you might not yet need to secure sensitive information in your deployment. However, when you are ready to deploy your application, you will want to encrypt the deployment files and passwords. Encrypting files and passwords encodes their contents so that they cannot be read by unauthorized users.

The process to encrypt files and passwords in your deployment is typically as follows:

1. Create a master password file using the NexJ Cipher Tool.

   

   Info

   If you have previously generated a master password file for your deployment, you do not need to perform this step unless you have changed the encryption password.

2. Encrypt your deployment files and passwords in NexJ Studio. Ensure that the encryption password matches the password in the master password file.
3. Set up password encryption on your application servers.

When you encrypt a file or password, you specify a master password that is used to encrypt it. When an application server or user tries to access the encrypted files or passwords, they must provide the master password in order to decrypt the information.

You can give application servers and users access to encrypted files and passwords without providing them with the master password. To do this, you provide them with a master password file. A master password file is a type of key that allows anyone who possesses it to decrypt information that was encrypted using the corresponding master password.

You encrypt deployment files and their passwords in the Deployment layer in NexJ Studio.

Encrypting deployment files

Encrypt files in your deployment when you want to prevent unauthorized access to the files. Encrypting files encodes their contents so that they are no longer displayed as plain text.

Deployment files can contain sensitive information such as user credentials and network information. By encrypting your deployment files, you ensure that only authorized users can read their contents.

When you encrypt a file, you specify a master password that is used to encrypt it. When an application server or user tries to access the encrypted file, they must provide the master password in order to decrypt the information.

You can encrypt .connections, .environment, and .server files.

To encrypt a file in your deployment:

1. In NexJ Studio, navigate to the Deployment layer.

2. In the Environments tab, right-click the file that you want to encrypt, select Encrypt → File, then choose the type of encryption that you want to use.
   base64
   Encrypts the file using Base64 encoding.

   

   Info

   Base64 is a standard encoding scheme that can be decoded by any party. It should not be used in production environment. In a secure development or test environment, it is useful for obscuring sensitive information such as password text.

   master
   Encrypts the file using a master password.
   If you select base64, the file is immediately encoded and you can skip the following steps.
   If you select master, the Master Password dialog is then displayed. You must next specify the password that will be used to encrypt and decrypt the file.

3. In the Enter Password field, enter the password that will be used to encrypt and decrypt the file.
   If you have already created a master password file for this deployment, the password that you enter should match the master password.
4. In the Re-enter Password field, enter the password again.
5. Click OK to encrypt the file using the password that you provided.
   The Master Password dialog closes.

You have encrypted the file in your deployment. You can navigate to the Source tab to confirm that the contents of the file have been encrypted. The source text should now appear as master: followed by the encoded content. Before you deploy your application, you must set up password encryption on your application server.

Encrypting passwords in deployment files

Encrypt passwords in your deployment files when you want to hide the passwords from unauthorized users.

Encrypting passwords encodes them so that they are no longer displayed as plain text.

After you encrypt the passwords in a deployment file, the password text is encoded. To decrypt the passwords, the application server or user that wants to access the passwords must provide the master password.

You can encrypt passwords in .connections, .environment, and .server files.

To encrypt the passwords in a deployment file:

1. In NexJ Studio, navigate to the Deployment layer.

2. In the Environments tab, right-click the file whose passwords you want to encrypt, select Encrypt → Password, then choose the type of encryption that you want to use.
   base64
   Encrypts the passwords using base64 encoding.

   

   Info

   Base64 is a standard encoding scheme that can be decoded by any party. It should not be used in a production environment. In a secure development or test environment, it is useful for obscuring sensitive information such as password text.

   
   master
   Encrypts the passwords using a master password.
   If you select base64, the passwords are immediately encrypted and you can skip the following steps.
   If you select master, the Master Password dialog is then displayed. You must next specify the master password that will be used to encrypt and decrypt the passwords in the file.

3. In the Enter Password field, enter the master password that will be used to decrypt the passwords in the file. If you have already created a master password file for this deployment, the password that you enter should match the master password.

4. In the Re-enter Password field, enter the password again.

5. Click OK to encrypt the passwords using the password that you provided.
   The Master Password dialog closes.

You have encrypted the passwords in the deployment file. You can navigate to the Source tab to confirm that the passwords have been encrypted. The text for each password should now appear as master: followed by the encoded content.

Before you deploy your application, you must set up password encryption on your application server.

Creating a master password file

Create a master password file that you can provide to application servers and users that need to access encrypted files and passwords in your deployment. A master password file allows you to give access to encrypted information in your deployment without directly providing the master password.

When you create a master password file, you specify the master password that is stored in the file.

Info

If you change the password that you use to encrypt files and passwords in your deployment, you must generate a new master password file.

Use the NexJ proprietary Cipher tool, available in NexJ Studio, to create the master password. 

Setting the contentType for requests to RPC endpoints and channels

As part of the fix for ECRM-29258: SSO exposed to CSRF, the NexJ framework is verifying the contentType for requests to RPC endpoints and channels where mismatched usage of vulnerable types "application/x-www-form-urlencoded", "multipart/form-data", "text/plain" are no longer allowed, and will trigger an "Unexpected request content type" error with HTTP status 415.

In cases where a vulnerable type in the request cannot be rejected due to being a matching contentType, the NexJ framework checks anti-CSRF tokens and if not successful, a "CSRF verification failed" error with HTTP status 403 or 404 will appear based on environment configuration.

All clients upgrading to NexJ CRM 22.11 must verify all areas of application integration. If any of the above errors are encountered, please verify that the contentType of the request matches the associated end point.