SECURE INSTALLATION AND CONFIGURATION
The Secure Installation and Configuration consists of following topics:
- Architecture Diagram
- Installing WebLogic
- Configuring SSL
- Disable SSLv3
- HTTP Response Header Configurations
- Password Policy Guidelines
- Configuring 2FA for login
- Configuring 2FA attributes
- Choosing a non blocking PRNG
- Mobile App SSL Pinning Configuration
This chapter provides an overview of the architecture of the deployment and describes the installation and configuration procedure for Oracle Banking Digital Experience.
Please note that this is only a guide to securing the Oracle Banking Digital Experience application and does not replace periodic reviews of the security architecture of the entire ecosystem of multiple applications maintained by the customer. The guidance provided in this document must always be augmented by specific understanding of the security considerations of the specific deployment architecture.
Architecture Diagram
Installing WebLogic
Installation of Weblogic Server can be done by referring to the documentation published at https://docs.oracle.com/cd/E24329_01/doc.1211/e24492/toc.htm
Configuring SSL
One way SSL between the presentation tier and the application on WebLogic server is supported. The detailed configuration is explained below:
Note: Procure an external CA signed certificate before proceeding further. Follow the instructions below to install the certificate once the certificate is available.
- Import the Certificate into a Java Trust Keystore
Execute the following command:
keytool -import -trustcacerts -alias sampletrustself -keystore SampleTrust.jks -file SampleSelfCA.cer.der -keyalg RSA keytool -import -alias `hostname -f` -file `hostname -f`.cer -keystore <JAVA_HOME>/jre/lib/security/cacerts -storepass changeit -noprompt
- Configure Application Domain’s Weblogic with Custom Identity and Trust Keystores
- Open the WebLogic admin console and navigate to Home --> Summary of Servers --> AdminServer.
- Click the Keystores tab.
- Click the Change button.
- Select Custom Identity and Java Standard Trust option from the list.
- Click the Save button.
- Enter the following details in the Identity and Trust sections:
Field |
Value |
---|---|
Custom Identity Keystore |
Absolute path of the custom keystore |
Custom Identity KeyStore Type |
JCEKS |
Custom Identity KeyStore Passphrase |
<Passphrase> |
Confirm Custom Identity KeyStore Passphrase |
<Re-enter the same Passphrase> |
Enter the passphrases that were used while creating the custom Identity Keystore and certificate.
- Click the Save button.
- Click the SSL Tab.
Enter the following details in the Identity section
Field |
Value |
---|---|
Private Key Alias |
<Alias> |
Private Key Passphrase |
<Passphrase>JCEKS |
Confirm Private Key Passphrase |
<Re-enter passphrase> |
- Enter the passphrases that were used while creating the certificate.
- Click the Save button.
- Click the Advanced link.
- Ensure that Two Way Client Cert Behavior is set to Client Certs Not Requested.
- Click the General tab.
- Select the SSL Listen Port Enabled check box.
- Click the Save button.
Disable SSLv3
By default, SSLv3 should be disabled.
Specifying the weblogic.security.SSL.protocolVersion system property in a command-line argument that starts the WebLogic Server lets you specify the protocol that is used for SSL connections.
The following command-line arguments can be specified so that WebLogic Server supports only TLS connections.
-Dweblogic.security.SSL.protocolVersion=TLS1
Note: If you don’t specify the above property, weblogic assumes SSLv3 by default.
HTTP Response Header Configurations
The following are some HTTP Response Headers that mitigate certain vulnerabilities.
Vulnerability |
HTTP Response Header |
||
---|---|---|---|
Clickjacking |
X-Frame-Options |
||
XSS |
|
||
Cookie hijacking Protocol Downgrade attacks |
Strict-Transport-Security |
||
Retrieving Sensitive data from browser cache |
Cache-Control |
The sections below specify how to configure these response headers in the httpd.conf file of the web server.
X-Frame-Options
Header always append X-Frame-Options SAMEORIGIN
Content-Security-Policy
Header set Content-Security-Policy "default-src 'none'; img-src 'self'
data:; script-src 'self' 'unsafe-inline' 'unsafe-eval'; style-src 'self'
https://fonts.googleapis.com 'unsafe-inline'; object-src 'none'; frame-src
'none'; font-src 'self' https://fonts.googleapis.com/
https://fonts.gstatic.com/ data:; connect-src 'self'
https://fonts.googleapis.com/ https://fonts.gstatic.com/ http://<OAM
Server>:<OAM Port>; manifest-src 'self'; child-src 'self'"
Please note that the policy mentioned here is for the base product. If the product gets customized and content from different URLs needs to be allowed to be executed by the browser, then this policy will have to be modified accordingly.
X-XSS-Protection
Header set X-XSS-Protection “1; mode=block”
Strict-Transport-Security
Set this for your top level domain. The header directive needs to be included inside the VirtualHost directive
<VirtualHost *:443>
Header always set Strict-Transport-Security “max-age=31540000; includeSubDomains”
</VirtualHost>
Consider submitting your website to be included in the HSTS preload list of websites maintained by Google Chrome at https://hstspreload.appspot.com/.
Other browsers like MS IE 11, MS Edge, Firefox and Opera also refer to this list maintained by Google and therefore the security offered by this mechanism will extend to other browsers too.
Cache-Control
Header set Cache-Control "max-age=0, no-cache, no-store, must-revalidate"
Header set Pragma "no-cache"
Header set Expires 0
Password Policy Guidelines
Our recommendations for setting a password policy are in line with the latest recommendations from NIST as of July 2017.
- The minimum length of a password must be at least 8 characters. You can choose to increase this number to 10 or 12.
- The maximum length of a password must be at least 64 characters. You can choose to increase this number to 80 or 100.
- Do not cause passwords to expire without reason. A password must be expired only when the user has forgotten it and has requested a reset.
- Allow all printable ASCII characters, including spaces, and accept all UNICODE characters too.
- Do not force the user to use a combination of upper case characters, lower case characters, numbers and special characters. Instead recommend to him that he uses “passphrases” instead of passwords, and that’s the reason why the recommended minimum length must be at least 8 and the maximum length must be at least 64. Passphrases are sentences like “Wow, I like the freedom to choose this password!!” (yes, with spaces, a comma and exclamation marks in it)
Password Policy Configuration
The password policy can be maintained in the Oracle Banking Digital Experience database or you can also set it in the LDAP user repository, if one is being used.
You need to specify your preference in the property shown below
A value of “true” in PROP_VALUE indicates that the password policy set in the local database needs to be applied.
A value of “false” in PROP_VALUE indicates that the password policy set in the LDAP user repository needs to be applied.
When PROP_VALUE is set to “true”, the password policy must be set in the database table DIGX_UM_PWD_POLICY. The following table lists the columns of the table and significance of each column:
Column Name |
Significance |
|||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
PASSWORDPOLICYID |
Unique Identifier for the password policy. |
|||||||||||||
PWD_POLICY_NAME |
Human friendly name given to the policy. |
|||||||||||||
PWD_MIN_LENGTH |
Minimum length of the password. |
|||||||||||||
PWD_MAX_LENGTH |
Maximum length of the password. |
|||||||||||||
CHAR_ALLOWED |
|
|||||||||||||
FIRST_CHAR_ALLOWED |
Characters allowed as the first character of a password. |
|||||||||||||
LAST_CHAR_ALLOWED |
Characters allowed as the last character of a password. |
|||||||||||||
NBR_UPPER_CASE |
Minimum number of upper case characters required in the password. |
|||||||||||||
NBR_LOWER_CASE |
Minimum number of lower case characters required in the password. |
|||||||||||||
NBR_NUMERIC_CHAR |
Minimum number of numeric characters required in the password. |
|||||||||||||
NBR_SPECIAL_CHAR |
Minimum number of special characters required in the password. |
|||||||||||||
SPECIAL_CHAR_ALLOWED |
List of special characters allowed in the password. |
|||||||||||||
NBR_REPEATED_CHAR |
Maximum number of times a character is repeated in the password. |
|||||||||||||
NBR_SUCCESSIVE_CHAR |
Maximum number of times a character can be repeated successively in the password. |
The following image shows the recommended values for the key columns of the database table DIGX_UM_PWD_POLICY.
Note: 1) The password policy ID and name are at your discretion and no specific recommendations are being made for them.
2) A different password policy can be set for each user group that you define. The password policy applicable for a particular user group can be defined in the table DIGX_UM_PWD_GROUP_MAP. That’s where the password policy ID will come in handy.
3) If you want the same password policy to be applicable for all groups then you can simply define just one policy in DIGX_UM_PWD_POLICY. You can leave the mapping table DIGX_UM_PWD_GROUP_MAP empty.
Configuring 2FA for login
Oracle Banking Digital Experience supports a 2nd factor of authentication during login.
- Login as the Admin user.
- Click on “Authentication”.
- Choose the user segment for which you want to configure 2FA for login and click on “View”.
- You will see the following screen where you can configure 2FA for virtually every transaction, including Login.
- Click on the “Edit” button at the bottom of the screen.
- You can now configure up to 2 factors (levels) of authentication / re-authorization. However please note that the system will not let you set “Security Questions” as a factor of authentication / re-authorization for the Login transaction. You will have to choose either OTP or Soft Token.
- Click on the “Save” button at the bottom of the screen, followed by the “Confirm” button seen in the subsequent verification screen.
Configuring 2FA attributes
This section covers some key attributes of the 2nd factor of authentication (re-authorization). Attributes like the maximum number of times a user is allowed to hit the “Resend” button after an OTP is generated, the pool of security questions etc are a couple of examples of 2FA attributes.
These attributes are seen in the database in the PROP_ID column of the table DIGX_FW_CONFIG_ALL_B (CATEGORY_ID = ‘authenticationConfig’). The following table lists down all possible attributes and their significance. Their values must be set in the column PROP_VALUE.
PROP_ID |
Significance |
---|---|
OTP.EXPIRATION_TIME |
Time in milliseconds after which an OTP will expire. |
T_SOFT_TOKEN.EXPIRATION_TIME |
Time in milliseconds after which a time based soft token will expire. |
R_SOFT_TOKEN.EXPIRATION_TIME |
Time in milliseconds after which a random soft token will expire. |
SEC_QUE.EXPIRATION_TIME |
Time in milliseconds after which answers to the security questions presented to the user will no longer be considered for re-authorization. |
EXPIRATION_TIME |
Time in milliseconds after which the re-authorization factor will expire. This is the default property that will be looked up in case factor specific expiration times are not maintained. |
OTP.MAX_NO_ATTEMPTS |
Max number of unsuccessful attempts of entering a valid OTP after which all 2FA enabled transactions for the user will be locked for a "cooling period" amount of time. |
T_SOFT_TOKEN.MAX_NO_ATTEMPTS |
Max number of unsuccessful attempts of entering a valid time based soft token after which all 2FA enabled transactions for the user will be locked for a "cooling period" amount of time. |
R_SOFT_TOKEN.MAX_NO_ATTEMPTS |
Max number of unsuccessful attempts of entering a valid random soft token after which all 2FA enabled transactions for the user will be locked for a "cooling period" amount of time. |
SEC_QUE.MAX_NO_ATTEMPTS |
Max number of unsuccessful attempts of entering valid answers to security questions after which all 2FA enabled transactions for the user will be locked for a "cooling period" amount of time. |
MAX_NO_ATTEMPTS |
Max number of unsuccessful attempts of entering valid 2FA after which all 2FA enabled transactions for the user will be locked for a "cooling period" amount of time. This is the default property that will be looked up in case factor specific Max Attempts are not maintained. |
TFA_LOCK_COOLING_PERIOD |
This is the cooling period in milliseconds after which 2FA transactions which were locked out because of exceeding MAX_NO_ATTEMPTS, are enabled once again. |
OTP.MAX_ACTIVE_REF_NO |
Max number of attempts to generate 2FA reference numbers for a transaction after which no more attempts can be made for EXPIRATION_TIME units of time for that factor of authentication. This one is specific to OTPs. This property is in place as a basic mechanism to protect the application against DOS attacks where the end user can keep generating OTPs by initiating transactions and making the system generate the 2nd factor of authentication, but not going through and completing the transaction. |
T_SOFT_TOKEN.MAX_ACTIVE_REF_NO |
Max number of attempts to generate 2FA reference numbers for a transaction after which no more attempts can be made for EXPIRATION_TIME units of time for that factor of authentication. This one is specific to Time Based Soft Tokens. |
R_SOFT_TOKEN.MAX_ACTIVE_REF_NO |
Max number of attempts to generate 2FA reference numbers for a transaction after which no more attempts can be made for EXPIRATION_TIME units of time for that factor of authentication. This one is specific to Random Soft Tokens. |
SEC_QUE.MAX_ACTIVE_REF_NO |
Max number of attempts to generate 2FA reference numbers for a transaction after which no more attempts can be made for EXPIRATION_TIME units of time for that factor of authentication. This one is specific to Security Questions. |
MAX_ACTIVE_REF_NO |
Max number of attempts to generate 2FA reference numbers for a transaction after which no more attempts can be made for EXPIRATION_TIME units of time for that factor of authentication. This is the default property that will be looked up in case factor specific Max Active Reference Number attempts are not maintained. |
OTP.RESEND_COUNT |
Max number of times a user can hit the “Resend” button in case of OTPs. After exceeding this count, the user will need to re-initiate the transaction all over again. |
retailuser.NO_QUE_ANS |
Number of security questions that a retail user needs to setup (answer). During an actual transaction he will be asked a sub set of these questions. |
corporateuser.NO_QUE_ANS |
Number of security questions that a corporate user needs to setup (answer). During an actual transaction he will be asked a sub set of these questions. |
administrator.NO_QUE_ANS |
Number of security questions that an admin user needs to setup (answer). During an actual transaction he will be asked a sub set of these questions. |
NO_QUE_ANS |
Number of security questions that a user segment needs to setup (answer). During an actual transaction he will be asked a sub set of these questions. This is the default property that will be looked up in case factor specific NO_QUES_ANS is not maintained. |
Choosing a non blocking PRNG
OBDX uses Java’s random number generation capabilities internally. However the out of the box algorithm for PRNG configured in the JDK can block the thread after a certain time if there isn’t enough randomness available. This is because the default configuration uses /dev/random on Linux for PRNG.
Therefore we recommend that you navigate to <JDK_HOME>/jre/lib/security and edit the java.security file. Comment out the old property and change its value as shown below.
This will ensure that the application uses /dev/urandom for PRNG.
Needless to say, make sure you make this change in the JDK that your weblogic server is going to be using.
Mobile App SSL Pinning Configuration
SSL Pinning has been implemented in the mobile apps, both iOS and Android. The public key certificate of the server needs to be imported into these apps for the connection to the server to be successful. The certificate needs to have an extension .cer and needs to be placed in mobile app workspaces as shown in the images below:
The name of the certificate file needs to be configured in a property file. For iOS it is the app.plist file.
For Android it is the app.properties file.