In the following, the example screenshots and texts are based on the following simple example:
All clients (browsers) with the client IP in the range 192.168.0.0/24 are in the context INTRANET
All other clients use the DEFAULT context.
The example only covers the Loginapp.
The following steps are required to make use of configuration contexts:
Configure context extraction.
Define contexts and the context retention policy.
Define context-specific values.
Step 1: Configure extraction
A context extractor plugin must be configured so Airlock IAM can determine the configuration context of the current request.
go to Loginapp >> Advanced Settings >> Context Extractor
Add a new context extractor plugin and configure it according to your requirements. For our example, add a new IP Context Extractor plugin and configure it accordingly.
Context extraction is defined similarly in the Transaction Approval and the API Policy Service modules.
Step 2: Define contexts
Configuration contexts have to be explicitly defined in the Config Editor. The default context always exists and does not have to be added. It is visible as the [DEFAULT] tab just above the properties of each plugin.
To add a new context (e.g. INTRANET), click on the + next to the context tabs and enter the name of the context. Then click the Create button.
The new context INTRANET is now visible as a tab in all plugins used in a module supporting contexts (Loginapp, Transaction Approval, API Policy Service).
Step 3: Define context-specific values
To define a context-dependent value for any property in the configuration:
Select the corresponding context tab above the properties list (INTRANET in our example).
Click on the overwrite icon (pencil) to overwrite the value inherited from the default context.
Edit the desired value (in the example below, the Max Failed Factor Attempts value is set to 10 for the context INTRANET)
Remember, that configuration contexts are only used in the Loginapp, the Transaction Approval, and the API Policy Service modules. Defining context-dependent values for other modules (Adminapp, Service container) has no effect.
Do not forget to activate the configuration changes
You can use the plugin Static Context Extractor to test whether the configured context-dependent values are as desired.