Authentication Settings

System Properties Relating to Authentication

Use the system properties listed in the table below to control different login aspects such as user sessions, password policy, and credentials. These settings allow you to strengthen the security of your Resolve Actions Pro deployment.

You can change system properties by going to Main Menu > System Administration > System Properties.

System property name	Description
authentication.defaultdomain	Default domain to use in case username is not prefixed with domain. Applies when authenticating against AD, LDAP, or RADIUS.
authentication.defaultmemberof	Default group assigned to the user if the external authentication does not return groups that the user is a member of. Applies when authenticating against AD, LDAP, RADIUS, or SiteMinder.
rsview.max.user.login.sessions	Maximum number of allowed concurrent sessions for a single user across the cluster. Set to 0 for unlimited sessions. Defaults: - Commercial: 0 - Government: 5
rsview.sessions.sync.interval	How often (in seconds) the RSView nodes will synchronize user sessions. Defaults to 15, which is also the minimum.
rsview.sessions.missed.sync.count	Number of synchronization attempts after which RSView will remove all remote sessions from its local cache if a sync message is not received back from the remote. Defaults to 2.
rsview.logout.users.onauthchange	Whether to log out users who were affected by a group or role change. Possible values: true, false. Defaults: - Commercial: false - Government: true
rsview.minimum.credential.age	Minimum user credentials age in minutes. The user is not allowed to change credential before they reach this age, preventing changing the credential in quick succession. Set to 0 to not perform the age check. If you set the minimum credential age to be greater than rsview.maximum.credential.age, the latter is implicitly increased to be one hour greater than rsview.minimum.credential.age. Defaults: - Commercial: 0 - Government: 1440 (24 hours)
rsview.maximum.credential.age	Maximum user credentials age in hours. The user is forced to change their credential when this age is reached. Setting it to 0 means the credentials never expire. If you set rsview.minimum.credential.age to be greater than rsview.maximum.credential.age, the latter is implicitly increased to be one hour greater than rsview.minimum.credential.age. Defaults: - Commercial: 0 - Government: 1440 (60 days)
users.credential.changeNewCharsRequired	Minimum number of password characters the user is required to change when replacing an expired password. This property helps ensure that users will not reuse the same password over and over again. The value is overwritten by users.credential.changeDistanceRequired if it is set. The value cannot exceed the minimum password length requirement (rsview.general.passwordrules.minCharLength). Defaults: - Commercial: 0 - Government: 8
users.credential.changeDistanceRequired	The minimum string distance (Levenshtein Distance) the user is required to keep when replacing an expired password. This property helps ensure that the user's new password deviates sufficiently from their previous password. If set, this property overwrites users.credential.changeNewCharsRequired. The value cannot exceed the minimum password length requirement (rsview.general.passwordrules.minCharLength). Defaults to 0.
session.fixed.timeout	Whether the user session timeout is a fixed period (true) or a sliding time window (false).In the former case, the user is always logged out after a fixed period of time (session.maxallowed) regardless of whether there is user activity or not. In the latter case, every user activity restarts the inactivity timeout. The session times out if there is no user activity for the value of session.timeout.
session.timeout	If session.fixed.timeout is false, this property defines a period (in seconds) of inactivity after which the user session expires and the user is logged out. Defaults to 43200 (12 hours). Minimum value is 720 (12 minutes).
session.maxallowed	If session.fixed.timeout is true, this property defines a fixed period (in seconds) after which the user session expires and the user is logged out. Setting this property to -1 means the user session will never expire. Minimum value is 720 (12 minutes).
users.admin.sessionTimeout	Period (in minutes) of inactivity after which the session of admin role users expires and they are logged out. Cannot exceed the value of session.timeout. Defaults: - Commercial: 0 - Government: 10
login.fail.attempts.allowed	Total number of failed login attempts before the user is locked out of their account for the duration configured in login.fail.attempts.duration. Defaults: - Commercial: 10 - Government: 3
login.fail.attempts.duration	Time period (in minutes) during which the limit on consecutive failed login attempts (login.fail.attempts.allowed) is enforced. If set to 0 or a negative value, the user is indefinitely locked out after login.fail.attempts.allowed is reached. An admin can manually unlock locked accounts. Defaults: - Commercial: 0 (disabled) - Government: 15 Examples: If login.fail.attempts.allowed is 10 and login.fail.attempts.duration is 0, the user will be locked out after consecutive 10 failed attempts. If login.fail.attempts.allowed is 3 and login.fail.attempts.duration is 15, the user will be locked out after three consecutive failed attempts within 15 minutes.

Multi-factor Authentication

You can configure Actions Pro to require a client security certificate on login in addition to the user credentials, providing another layer of security. You will then have to install a per-user client security certificate on every client machine or browser that is used to log in to Actions Pro.

You need to take the configuration steps laid out in the sections below to set up multi-factor authentication (MFA). After completing the steps, RSView will only accept a login if it is coming from a machine with a client certificate installed and if the username being sent matches the user who has been issued the certificate.

Setting Up a Certification Authority

You can set up MFA in Actions Pro using both a trusted certification authority (CA) and a custom CA that you set up.

Using a Trusted CA

Setting up a trusted CA involves ensuring that your CA is trusted on both the server and client sides and generating client certificates.

Setting Up Trusts

When using a trusted CA for MFA, you need to ensure that the CA is trusted by both OpenJDK on the server side and the web browser on the client side.

If the CA is trusted on both sides, you can skip the rest of this section.

If the CA is not trusted by OpenJDK, you need to import the CA root certificate into the Java trust store.

The default Java trust store is located at /opt/resolve/jdk/lib/security/cacerts (replace /opt/resolve with the actual base path of your installation). It is recommended to copy it to /opt/resolve/jdk/lib/security/jssecacerts before using it and then use jssecacerts exclusively. The jssecacerts copy is the trust store used throughout this document.

cp /opt/resolve/jdk/lib/security/cacerts /opt/resolve/jdk/lib/security/jssecacerts

Depending on how your CA distributes certificates, use one of the following options to import the CA certificate into your Java trust store:

• In case your CA provides X.509 certificates in PEM (Base64 ASCII) or DER (binary) format, use the following command to import it:

  keytool -importcert alias mfa-ca -file <server-cert> -keystore <your JKS> -storepass <store-password> -noprompt
  Where:
  • mfa-ca is how you are naming the imported certificate for the purposes of this trust store.
  • <server-cert> is the CA certificate that you are importing. The file extension can vary depending on the CA.
  • <your JKS> is the full path to the Java trust store where you are importing the certificate.
  • store-password is the passphrase that protects the trust store.
• In case your CA provides a PKCS 12 key store instead of a certificate, you can import its content into a Java trust store using the following command:

  keytool -importkeystore -srckeystore <PKCS 12 server cert> -srcstoretype pkcs12 -destkeystore <your JKS> -deststoretype jks
  Where:
  • <PKCS 12 server cert> is the PKCS 12 key store provided by the CA.
  • <your JKS> is the full path to the Java trust store where you are importing the certificate.

Generating Client Certificates

You need to generate a PKCS 12 client certificate for each user who will be logging in to Actions Pro. Later, you will install this certificate on the user machine. You can skip this section if you already have certificates generated.

When using a trusted CA, follow the instructions provided by the CA on how to generate and submit a certificate signing request. The following steps serve as a guideline on how to do it using OpenSSL:

1. Generate a private key for the client certificate:

   openssl genrsa -passout pass:<password> -out <username/>.key 2048
   Where:
   • username is the username used to log in to Actions Pro.
   • password is a passphrase that will be used to protect the key.
2. Generate a certificate signing request, making sure you specify the correct Actions Pro username as a request subject.
   Optionally, provide the user's email address when prompted.

   openssl req -new -key <username>.key -passin pass:<password> -out <username>.csr -subj "/CN=<username>"
   Where:
   • <username>.key is the private key file that you generated in the previous step.
   • password is passphrase that will be used to protect the generated request.
   • <username> is the username used to log in to Actions Pro.
   • "/CN=<username>" is the attribute type that contains the user ID that you want to use with Action Pro. It can be CN or another suitable attribute. See also Configuring the Blueprint.
3. Submit the certificate signing request to your CA and request a certificate.

If the CA provides you with a client certificate in a format other than PKCS 12, use the following command to convert it to PKCS 12:

Convert the certificate to the pkcs12 format required by web browsers:

openssl pkcs12 -export -inkey <username>.key -in <username>.crt -out <username>.p12

Where:

• <username>.key is the file name of the private key provided by the CA.
• <username>.crt is the file name of the certificate provided by the CA.
• <username>.p12 is how you want to name the converted certificate.

Using a Custom CA

Using a custom CA involves setting up the CA, setting up a Java trust store, and issuing client certificates.

Setting up a Certification Authority

You can set up your own CA using the tools you prefer. The example steps below use OpenSSL to create a CA and a trust store that you will later use to verify client and server certificates.

note

Preferably, use the same CA for the RSView server certificate and client authentication. Some web browsers might reject the trust otherwise.

1. Generate a root key:

   openssl genrsa -des3 -passout pass:<password> -out rootCA.key 4096
   Where:
   • password is a passphrase that will be used to protect the key.
   • rootCA.key is a file name where you want to write the key.
2. Generate a root certificate:

   openssl req -x509 -new -nodes -key rootCA.key -passin pass:<password> -sha256 -days 365 -out rootCA.crt -subj "/CN=<fqdn-of-issuer>"
   Where:
   • rootCA.key is the root key file that you generated.
   • password is the passphrase that protects the root key.
   • rootCA.crt is a file name where you want to write the root certificate.
   • <fqdn-of-issuer> is the domain name of the CA. It does not have to match the Actions Pro domain name.

Setting Up a Java Trust Store

As RSView runs on Java, you need to make sure that Java is aware of your CA. The default installation of Java comes with a Java trust store that you can use.

The default Java trust store is located at /opt/resolve/jdk/lib/security/cacerts (replace /opt/resolve with the actual base path of your installation). It is recommended to copy it to /opt/resolve/jdk/lib/security/jssecacerts before using it and then use jssecacerts exclusively. The jssecacerts copy is the trust store used throughout this document.

cp /opt/resolve/jdk/lib/security/cacerts /opt/resolve/jdk/lib/security/jssecacerts

After creating the copy, import the CA certificate using the following command:

keytool -import -v -trustcacerts -alias tomcat-ca -file rootCA.crt -keystore /opt/resolve/jdk/lib/security/jssecacerts -storepass <store-password> -noprompt

Where:

• tomcat-ca is how you are naming the imported certificate for the purposes of this trust store.
• rootCA.crt refers to the CA certificate that you generated.
• store-password is the passphrase that protects the trust store. The default jssecacerts password is "changeit". Changing it is highly recommended.

Generating Client Certificates

You need to generate a PKCS 12 client certificate for each user who will be logging in to Actions Pro. You can skip this section if you already have certificates generated.

Later, you will install the certificate on the user machine.

Use your preferred PKI tool to generate the key. The following example shows how to generate it with OpenSSL.

1. Generate a private key for the client certificate:

   openssl genrsa -passout pass:<password> -out <username>.key 2048
   Where:
   • username is the username used to log in to Actions Pro.
   • password is a passphrase that will be used to protect the key.
2. Generate a certificate signing request, making sure you specify the correct Actions Pro username as a request subject.
   Optionally, provide the user's email address when prompted.

   openssl req -new -key <username>.key -passin pass:<password> -out <username>.csr -subj "/CN=<username>"
   Where:
   • <username>.key is the private key file that you generated in the previous step.
   • password is passphrase that will be used to protect the generated request.
   • <username> is the username used to log in to Actions Pro.
   • "/CN=<username>" is the attribute type that contains the user ID that you want to use with Action Pro. It can be CN or another suitable attribute. See also Configuring the Blueprint.
3. Create a file named cert.ext and include the following certificate extensions in it:

   basicConstraints = CA:FALSE
   nsCertType = client, email
   nsComment = "OpenSSL Generated Client Certificate"
   subjectKeyIdentifier = hash
   authorityKeyIdentifier = keyid,issuer
   keyUsage = critical, nonRepudiation, digitalSignature, keyEncipherment
   extendedKeyUsage = clientAuth, emailProtection
4. Generate an X.509 certificate for the user:

   openssl x509 -req -in <username>.csr -CA rootCA.crt -CAkey rootCA.key -passin pass:<password> -CAcreateserial -out <username>.crt -days 365 -sha256 -extfile cert.ext
   Where:
   • <username>.csr is the certificate signing request file that you generated earlier.
   • rootCA refers to the certificate (.crt ) and private key (.key) files provided by your CA. The file names will vary depending on how the files were generated.
   • password is passphrase that will be used to protect the generated certificate.
   • <username> is the username used to log in to Actions Pro.
5. (Optional) Copy the generated .crt file to an eponymous .pem file if the .pem extension is required.

   cp <username>.crt <username>.pem
   Where username is the username used to log in to Actions Pro.
6. Verify the certificate:

   openssl rsa -noout -text -in <username>.key
   openssl req -noout -text -in <username>.csr
   openssl x509 -noout -text -in <username>.crt
   Where username is the username used to log in to Actions Pro.
7. Convert the certificate to the pkcs12 format required by web browsers:

   openssl pkcs12 -export -inkey <username>.key -in <username>.crt -out <username>.p12
   Where username is the username used to log in to Actions Pro.

Configuring the Blueprint

After taking care of the server and client certificates, you need to reconfigure Action Pro through its blueprint.properties file, enabling MFA and specifying the CA details.

Take these steps to reconfigure blueprint.properties:

1. Open the file for editing:

   vi /opt/resolve/bin/blueprint.properties
2. Enable the mandatory use of client certificates for authentication:

   rsview.auth.clientcertificate.verification=required
3. Configure the attribute type used in client certificates to identify the user.
   The attribute type set here must match the attribute type (CN, EMAILADDRESS, and so on) that stores the user identifier inside the client certificate.

   rsview.auth.clientcertificate.key=CN
4. Configure the location of the Java trust store to use to validate client certificates:

   # Set to the full path to the Java trust store,  
   # e.g. to /opt/resolve/jdk/lib/security/jssecacerts if using
   # the default Java trust store.
   rsview.tomcat.connector.https.truststoreFile=/opt/resolve/jdk/lib/security/jssecacerts
   # The default jssecacerts password is "changeit". Changing it is highly recommended.
   rsview.tomcat.connector.https.truststorePassword=<password for the .jks trust store>
5. Save the file.
6. Apply the configuration changes:

   # stop all services
   <actions-home>/bin/stop.sh all
   # verify all services are stopped
   <actions-home>/bin/status.sh all
   # apply the configuration
   <actions-home>/bin/config.sh
   # start all services
   <actions-home>/bin/run.sh all

Configuring the Client Machine or Web Browser

After generating the client certificate, you need to set it up on the client machine. Depending on the OS, you will do that either on OS level or in the web browser used to log in to Action Pro. You need to set up the certificate in each web browser separately if you plan on using more than one.

Safari

Safari will pick up the certificate from the MacOS Keychain. Import the .p12 file using the Keychain Access utility following the official MacOS documentation. Ensure you do the import in the System keychain, on the My Certificate tab.

Firefox

You need to import the certificate in Firefox, regardless of the OS.

1. Open the Firefox menu and click Settings.
2. In the side navigation, click Privacy & Security.
3. Under Certificates, click View Certificates.
4. In Certificate Manager, click the Your Certificates tab.
5. Click Import.
6. (For custom CA) On the Authorities tab, import the custom CA certificate.
7. Select the .p12 file from your machine.

Chrome

You need to import the certificate in Chrome, regardless of the OS.

1. Open the Chrome menu and click Settings.
2. In the side navigation, click Privacy and Security.
3. Click Security.
4. Click Manage Certificates.
5. Click Import.
6. Click Import.
7. Follow the wizard to import the .p12 file from your machine.