Configuring Next Step
This chapter describes the post-install configuration of Next Step Server. Use it after the server is deployed, the database schema is prepared, and the runtime properties are configured.
During Next Step deployment organizations need to be customized. In case Next Step is used to store user identities, additional configuration of credential and one time password policies and definitions is required. The customization is usually done using SQL, however a RESTful API is also available for each of the configuration steps.
Before You Start
Before continuing with the configuration below, make sure that:
- Next Step Server is installed, configured and reachable, see Next Step Server Installation
Recommended Configuration Order
For a new installation, configure Next Step in the following order:
- organizations
- Next Step applications
- credential and OTP policies
- credential and OTP definitions
If configuration is managed as SQL migrations, keep the same order in your deployment pipeline so that reference data dependencies remain valid.
Organization Configuration
Next Step requires at least one organization configured.
Each organization requires following configuration:
organization_id- an identifier of the organization, such asRETAILorSMEdisplay_name_key- internationalization key for the organization used in Web Flow when displaying organization nameis_default- whether the organization is the default one, set this flag toTRUEonly for one organizationorder_number- order of the organization in the Web Flow UI, starting by 1default_credential_name- default credential name is used by Web Flow when performing credential authentication using Next Stepdefault_otp_name- default OTP name is used by Web Flow when performing OTP authentication using Next Step
The default configuration is following:
INSERT INTO ns_organization (organization_id, display_name_key, is_default, order_number, default_credential_name, default_otp_name) VALUES ('RETAIL', 'organization.retail', 1, 1, 'RETAIL_CREDENTIAL', 'RETAIL_OTP');
The default configuration assigns the RETAIL organization to all operations. You can define multiple organizations to support
authentication for multiple segments which can have overlapping user IDs, e.g.:
INSERT INTO ns_organization (organization_id, display_name_key, is_default, order_number, default_credential_name, default_otp_name) VALUES ('RETAIL', 'organization.retail', 1, 1, 'RETAIL_CREDENTIAL', 'RETAIL_OTP');
INSERT INTO ns_organization (organization_id, display_name_key, is_default, order_number, default_credential_name, default_otp_name) VALUES ('SME', 'organization.sme', 0, 2, 'SME_CREDENTIAL', 'SME_OTP');
Such configuration defines two organizations RETAIL and SME. The user sees two tabs when authenticating with localized labels
based on keys organization.retail and organization.sme. The user can switch the organization against which the authentication is performed.
The RETAIL organization is the default one (it is preselected in the UI). The order of displayed organizations is defined as
RETAIL, SME using the last parameter.
User ID should represent a natural person. Make sure the user ID used in Next Step Server is consistent in all PowerAuth backends. You can achieve this requirement by assigning unique user IDs in different organizations during user authentication. Alternatively the uniqueness requirement can be achieved by adding a prefix to all user IDs based on the organization against which the user was authenticated (e.g. RETAIL.12345678).
The organization can be created using REST API by calling the POST /organization endpoint.
Configuration of Next Step Applications
At least one Next Step application must be configured. Each application requires following configuration:
application_id- Next Step application identifiername- application namedescription- description of the applicationstatus- application status:ACTIVEorREMOVEDtimestamp_created- timestamp when application was created
INSERT INTO ns_application (application_id, name, description, status, timestamp_created) values (1, 'APP', 'Sample application', 'ACTIVE', CURRENT_TIMESTAMP);
The application can be created using REST API by calling the POST /application endpoint.
Configuration of Next Step Credential Policies
At least one Next Step credential policy must be configured in case credential authentication is performed. The configuration is not used when Data Adapter proxy is enabled, in this case the configuration record is prepared for potential future switch to Next Step identity once Data Adapter proxy is disabled.
The credential policy requires following configuration:
credential_policy_id- credential policy identifiername- credential policy namedescription- description of the credential policystatus- credential policy status:ACTIVEorREMOVEDusername_length_min- minimum length of the username, useNULLvalue for no limitusername_length_max- maximum length of the username, useNULLvalue for no limitusername_allowed_pattern- regular expression for checking the username pattern, useNULLvalue for no checkcredential_length_min- minimum length of the credential, useNULLvalue for no limitcredential_length_max- maximum length of the credential, useNULLvalue for no limitlimit_soft- soft limit for failed authentication attempts using credential (credential statusBLOCKED_TEMPORARYwhen limit is exceeded), usenullvalue for no limit (e.g. for development purposes)limit_hard- hard limit for failed authentication attempts using credential (credential statusBLOCKED_PERMANENTwhen limit is exceeded), usenullvalue for no limit (e.g. for development purposes)check_history_count- count of historical credential values which should be checked when changing the credential, use0for skipping the checkrotation_enabled- whether credential rotation is enabledrotation_days- number of days for credential rotation, only specify when credential rotation is enabledcredential_temp_expiration- expiration ofTEMPORARYcredentials in secondsusername_gen_algorithm- name of algorithm used for generating username:NO_USERNAME,RANDOM_DIGITS, orRANDOM_LETTERSusername_gen_param- parameters of the username generating algorithm:length(only applies to algorithmsRANDOM_DIGITSandRANDOM_LETTERS)credential_gen_algorithm- name of algorithm used for generating credentials:RANDOM_PASSWORDorRANDOM_PINcredential_gen_param- parameters of the credential generating algorithm:length,includeSmallLetters,smallLettersCount,includeCapitalLetters,capitalLettersCount,includeDigits,digitsCount,includeSpecialChars,specialCharsCountcredential_val_param- parameters of credential validation based on the Passay library rules:includeWhitespaceRule,includeUsernameRule,includeAllowedCharacterRule,allowedChars,includeAllowedRegexRule,allowedRegex,includeIllegalCharacterRule,illegalChars,includeIllegalRegexRule,illegalRegex,includeCharacterRule,includeSmallLetters,smallLettersMin,includeCapitalLetters,capitalLettersMin,includeAlphabeticalLetters,alphabeticalLettersMin,includeDigits,digitsMin,includeSpecialChars,specialCharsMintimestamp_created- timestamp when credential policy was created
INSERT INTO ns_credential_policy (credential_policy_id, name, description, status, username_length_min, username_length_max, username_allowed_pattern, credential_length_min, credential_length_max, limit_soft, limit_hard, check_history_count, rotation_enabled, username_gen_algorithm, username_gen_param, credential_gen_algorithm, credential_gen_param, credential_val_param, timestamp_created) values (1, 'CREDENTIAL_POLICY', 'Sample credential policy', 'ACTIVE', 8, 20, '[0-9]+', 8, 40, 3, 5, 3, 0, 'RANDOM_DIGITS', '{"length": 8}', 'RANDOM_PASSWORD', '{"length": 12, "includeSmallLetters": true, "smallLettersCount": 5, "includeCapitalLetters": true, "capitalLettersCount": 5, "includeDigits": true, "digitsCount": 1, "includeSpecialChars": true, "specialCharsCount": 1}', '{"includeWhitespaceRule": true, "includeUsernameRule": true, "includeAllowedCharacterRule": false, "allowedChars": "", "includeAllowedRegexRule": false, "allowedRegex": ".*", "includeIllegalCharacterRule": false, "illegalChars": "", "includeIllegalRegexRule": false, "illegalRegex": "", "includeCharacterRule": true, "includeSmallLetters": "true", "smallLettersMin": 1, "includeCapitalLetters": true, "capitalLettersMin": 1, "includeAlphabeticalLetters": true, "alphabeticalLettersMin": 2, "includeDigits": true, "digitsMin": 1, "includeSpecialChars": true, "specialCharsMin": 1}', CURRENT_TIMESTAMP);
The credential policy can be created using REST API by calling the POST /credential/policy endpoint.
Configuration of Next Step OTP Policies
At least one Next Step OTP policy must be configured in case OTP authentication is performed. The configuration is not used when Data Adapter proxy is enabled, in this case the configuration record is prepared for potential future switch to Next Step identity once Data Adapter proxy is disabled.
The OTP policy requires following configuration:
otp_policy_id- OTP policy identifiername- OTP policy namedescription- description of the OTP policystatus- OTP policy status:ACTIVEorREMOVEDlength- length of the OTP authorization codeattempt_limit- limit for failed authentication attempts using OTP (OTP statusBLOCKEDwhen limit is exceeded), use0for no limitexpiration_time- expiration of OTP recordgen_algorithm- name of algorithm used for generating OTP authorization code:OTP_DATA_DIGESTorOTP_RANDOM_DIGIT_GROUPSgen_param- parameters of the OTP authorization code generating algorithm:groupSize(only applies to algorithmOTP_RANDOM_DIGIT_GROUPS)timestamp_created- timestamp when OTP policy was created
INSERT INTO ns_otp_policy (otp_policy_id, name, description, status, length, attempt_limit, expiration_time, gen_algorithm, gen_param, timestamp_created) values (1, 'OTP_POLICY', 'Sample OTP policy', 'ACTIVE', 8, 3, 300, 'OTP_DATA_DIGEST', '{}', CURRENT_TIMESTAMP);
The OTP policy can be created using REST API by calling the POST /otp/policy endpoint.
Configuration of Next Step Credential Definitions
At least one Next Step credential definition must be configured in case credential authentication is performed. The configuration is not used when Data Adapter proxy is enabled, in this case the configuration record is prepared for potential future switch to Next Step identity once Data Adapter proxy is disabled.
The credential definition requires following configuration:
credential_definition_id- credential definition identifiername- credential definition namedescription- description of the credential definitionapplication_id- application identifierorganization_id- organization identifiercredential_policy_id- credential policy identifiercategory- credential category:PASSWORD,PIN, orOTHERencryption_algorithm- encryption protection of stored passwords useAES_HMACwhen enabled orNO_ENCRYPTIONhashing_enabled- enable if the password should be hashed instead of encryptedhashing_config_id- reference to a hash configuration, required whenhashing_enabledis truedata_adapter_proxy_enabled- whether credential verification requests should be proxied via Data Adapterstatus- credential definition status:ACTIVEorREMOVEDtimestamp_created- timestamp when credential definition was created
INSERT INTO ns_credential_definition (credential_definition_id, name, description, application_id, organization_id, credential_policy_id, category, encryption_algorithm, data_adapter_proxy_enabled, status, timestamp_created) values (1, 'RETAIL_CREDENTIAL', 'Sample credential definition for retail', 1, 'RETAIL', 1, 'PASSWORD', 'NO_ENCRYPTION', 0, 'ACTIVE', CURRENT_TIMESTAMP);
The Credential definition can be created using REST API by calling the POST /credential/definition endpoint.
Configuration of Hashing
For stored credentials values, i.e. passwords, the value can be hashed instead of encrypted. This allows safer storing of the value, but the actual value is not known to the server and cannot be obtained via API.
The configuration parameters:
hashing_config_id- hash configuration identifiername- name of configurationalgorithm-ARGON_2D,ARGON_2I,ARGON_2ID,BCRYPTstatus- hash configuration status:ACTIVEorREMOVEDparameters- for BCRYPT use empty parameterization otherwise use argon related parameters
INSERT INTO ns_hashing_config (hashing_config_id, name, algorithm, status, parameters) values (1, 'ARGON', 'ARGON_2ID', 'ACTIVE', '{"version":"16","iterations":"3","memory":"15","parallelism":"16","outputLength":"32"}' )
The hashing configuration can be created using REST API by calling the POST /hashconfig endpoint.
Configuration of Next Step OTP Definitions
At least one Next Step OTP definition must be configured in case OTP authentication is performed. The configuration is not used when Data Adapter proxy is enabled, in this case the configuration record is prepared for potential future switch to Next Step identity once Data Adapter proxy is disabled.
The OTP definition requires following configuration:
otp_definition_id- OTP definition identifiername- OTP definition namedescription- description of the OTP definitionapplication_id- application identifierotp_policy_id- OTP policy identifierdata_adapter_proxy_enabled- whether OTP verification requests should be proxied via Data Adapterstatus- OTP definition status:ACTIVEorREMOVEDtimestamp_created- timestamp when OTP definition was created
INSERT INTO ns_otp_definition (otp_definition_id, name, description, application_id, otp_policy_id, data_adapter_proxy_enabled, status, timestamp_created) values (1, 'RETAIL_OTP', 'Sample OTP definition for retail', 1, 1, 0, 'ACTIVE', CURRENT_TIMESTAMP);
The OTP definition can be created using REST API by calling the POST /otp/definition endpoint.