Example: Create environment files to capture extDB changes
For this use case, a product implementer for XYZ company has set up two product server environments, one for development and one for production. Each environment has different requirements for the method emails are sent, the amount of failed login attempts permitted before user lockout is triggered and the length of the PIN required for multi-factor authentication. These configuration requirements differ from the defaults configured by components.
This configuration example shows how to create dev and prod environment files to capture entry differences within the ExtDB tables for authentication chains and email behavior. Then, it demonstrates how to load the development environment file during an installation on the development environment.
The environment configuration requirements are:
Emails should be sent to:
FILE only in dev.
SMTP only in prod.
The number of failed login attempts permitted are:
6 attempts for dev.
default attempts for prod (default value is 3).
The PIN lengths for multi-factor authentication are:
PIN length of 4 for dev.
default PIN length for prod (default value is 5).
The following steps need to be completed:
Identify the component needed for the desired external data store override using a test environment with the product installed.
On the test product instance, review the default configurations that the Functional.hid_policy_wfemail component enters into the hid_policy_wfemail policy table.
Create the dev environment file.
Create the prod environment file.
Load the dev environment file on the development environment.
Install the Functional.hid_policy_wfemail component on the development environment.
Requirements
This use case assumes that:
A test product instance is available for testing configurations with the Functional.hid_policy_wfemail component installed.
By default installing the Functional.hid_policy_wfemail component results in emails being sent both to FILE and SMTP server.
On a development and production environment, the following is true:
Bravura Security Fabric and Bravura Security Connector Pack are installed.
An Active Directory target system is added as a source of profiles.
Click below to view a demonstration.
Identify the component that you want to add the override for
A test instance has been setup with a variety of components installed in order to identify the component that configuration changes need to be made to.
Identifying the component for an External data store override is much easier than identifying one for idmconfig changes (in most cases). If you already have an existing instance, you can generally determine which component provides specific rows to a table by looking at the ComponentOwnerFQN field that is included in all external data store tables.
To identify the component:
Log in to Bravura Security Fabric Front-end (PSF) as superuser .
Click Manage External Data Store.
Navigate to the table in question. This might take some guess work until you find the table and rule responsible for the configuration you're trying to alter. For this example, since email settings need to be altered, it’s a good guess to check the hid_policy_wfemail table.
Identify the row you want to override, and note the value of its ComponentOwnerFQN field. For this example, the first rule in this table, where EventID = _DEFAULT_POLICY , shows SendSMTP and WriteFile columns set to True . Scrolling over to the ComponentOwnerFQN field shows it is configured by the Functional.hid_policy_wfemail component. This means the override needs to be applied to the Functional.hid_policy_wfemail component.
Now that we have identified the component to override, the specific component file to override also needs to be determined. For data provided to ExtDB tables, this generally comes from .csv files.
Review default configuration settings for wfemail component
To determine which specific file and fields we need to provide overrides for in the dev environment file:
Navigate to the \<instance>\component\default\functional\hid_policy_wfemail directory.
Open and inspect
manifest.xml
for configdata entries.From the entries, we find the configdata entry shows:
<configdata component="Functional.hid_policy_wfemail.model.PolicyWFEmail"> <filename>data\events.csv</filename> </configdata>
From the placement within configdata entries, it is shown that the file providing configuration information is \data\ events.csv . This information is now used to start building a structure for the dev environment file.
Note
The / and \ are not equivalent; the slash in the environment file must match the type used in
manifest.xml
.
Create the dev environment file
To create the dev environment file, if it does not already exist:
Navigate to your \<instance> directory.
If an \<instance>\environments folder does not currently exist in the instance directory, create one.
Inside the \environments directory, open an appropriate application (like Notepad++ ) to create a new file called
xyz-dev.json
.This will act as the dev environment file. If this file exists already, you only need to add to it.
Override the appropriate CSV rows in the environment file
To write the dev environment file:
Edit the
xyz-dev.json
file and add the three keys to indicate the component directories by entering the following:{ "Scenario": {}, "Functional": {}, "Data": {} }
Now that there is a basic skeleton, it is known that the component of interest is in the \Functional directory, so the override is added under the " Functional " key so the file now looks like:
{ "Scenario": {}, "Functional": { "hid_policy_wfemail": {} }, "Data": {} }
The file being overridden from the component now needs to be specified. It was determined above to be
\data\ events.csv
, so that is added next.{ "Scenario": {}, "Functional": { "hid_policy_wfemail": { "data\\events.csv": {} } }, "Data": {} }
Writing overrides for .csv files is similar to how overrides are written for .json files, but for .csv files the specific rows being altered need to be identified in the environment file. For this example, the row in the events.csv file where EventID = _DEFAULT_POLICY is being overridden, so the number of this row needs to be recorded in the environment file.
To find the number of the row, open the \<instance>\component\Default\Functional\hid_policy_wfemail\data\ events.csv file and see which line EventID = _DEFAULT_POLICY .
Viewing the file shows the line with EventID = _DEFAULT_POLICY happens to be the first item in the .csv . To specify the row in the environment file, its index (zero-indexed) needs to be added followed by the fields you want to override for that row. Since EventID = _DEFAULT_POLICY is the first row in the .csv , it has an index of ’0’. The xyz-dev.json environment file then looks like:
{ "Scenario": {}, "Functional": { "hid_policy_wfemail": { "data\\events.csv": { "[0]": { } } } }, "Data": {} }
The Functional.hid_policy_wfemail component by default configures both SendSMTP and WriteFile values to be set to True . Since the development environment is supposed to send emails to file only, the override required is setting the SendSMTP field to FALSE . The environment file override entry in xyz-dev.json then becomes:
{ "Scenario": {}, "Functional": { "hid_policy_wfemail": { "data\\events.csv": { "[0]": { "SendSMTP": "FALSE" } } } }, "Data": {} }
With this change, when the xyz-dev.json environment is loaded before installing the Functional.hid_policy_wfemail component, the first row of the hid_policy_wfemail policy table is configured with SendSMTP = FALSE . Thus, overriding the default value of SendSMTP = TRUE from the events.csv file.
Create the prod environment file
Create the prod environment file if it does not already exist:
Navigate to your \<instance> directory.
If an \<instance>\environments folder does not currently exist in the instance directory, create one.
Inside the \environments directory, open an appropriate application (like Notepad++ ) to create a new file called
xyz-prod.json
.This will act as our prod environment file. If this file exists already, you only need to add to it.
Override the appropriate CSV rows in the environment file
Following similar steps and logic to the dev environment file, the xyz-prod.json file is written to include an override that ensures email in the prod environment is set to SMTP only and not to file. This means the WriteFile field from the events.csv must be overridden to equal FALSE.
{ "Scenario": {}, "Functional": { "hid_policy_wfemail": { "data\\events.csv": { "[0]": { "WriteFile": "FALSE" } } } }, "Data": {} }
Load the dev environment file
This example assumes the development server environment has Bravura Security Fabric installed on the system without the installation of the Functional.hid_policy_wfemail component.
Navigate to the \<instance> directory and create the \ environments directory.
Copy your xyz-dev.json file into that directory.
Launch a command prompt as an Administrator and navigate to the \<instance> directory.
Run the command:
instance.bat
Navigate to the \<instance>\script directory.
Load the environment file by running the commands:
manage_components.py load manage_components.py env load xyz-dev
Install Functional.hid_policy_wfemail component
To install the Functional_hid_policy_wfemail component:
While still in the \<instance>\script directory, list the components by running the command (note: the component is case sensitive):
Manage_components.py install Functional.hid_policy_wfemail
You know the command has run successfully if the command prompt shows the built and installed skins.
Additionally, you can check the hid_policy_wfemail ExtDB table entries:
Verify that the SendSMTP value has been configured as FALSE by checking the value in the hid_policy_wfemail EXTdb table:
Log in to Bravura Security Fabric as superuser .
Click Manage External Data Store.
Navigate to the hid_policy_wfemail table.
Review the first rule in the table where EventID = _DEFAULT_POLICY and ensure that the value for SendSMTP = FALSE.
Adding multiple pieces of configuration to an environment file
Since environment files are just .json files, adding more configuration is as simple as adding a comma, and defining another item to override. To display this, we will extend our xyz-dev.json to override the LENGTH and TRIES configurable values provided by the Scenario.hid_authchain_emailpin component to GlobalConfiguration to make the email PIN scenario easier to use in development environments.
For reference, the manifest.xml file for the Scenario.hid_authchain_emailpin component has GlobalConfiguration data provided by the \data\ initial_data.csv file. The default values in the \data\ initial_data.csv file consist of:
row 3 with LENGTH = 5
row 4 with TRIES = 3
In this example, an override is added to the xyz-dev.json file so that:
LENGTH = 4
TRIES = 6
Writing the override into the existing xyz-dev.json
file appears as:
{ "Scenario": { "hid_authchain_emailpin": { "data\\initial_data.csv": { "[2]": { "value": "4" }, "[3]": { "value": "6" } } } }, "Functional": { "hid_policy_wfemail": { "data\\events.csv": { "[0]": { "WriteFile": "FALSE" } } } }, "Data": {} }
Note that just because the override has been added for the component Scenario.hid_authchain_emailpin to the xyz-dev.json environment file, it does not mean an override needs to be added to other environment files. For example, since the default values being provided by the component suit the needs of the production environment, no further entries need to be added to the xyz-prod.json file. The resulting xyz-prod.json file will still appear as:
{ "Scenario": {}, "Functional": { "hid_policy_wfemail": { "data\\events.csv": { "[0]": { "WriteFile": "FALSE" } } } }, "Data": {} }