Supporting scenarios
Bravura Pattern includes a number of components which provide shared functionality for other scenarios. We call these "supporting" or "library" components.
When the onboarding scenarios described above are installed, the supporting scenarios described below are also installed as dependencies.
im_corp_onboard
Purpose:
This scenario provides configuration data, library methods and scripted logic required by other scenarios which provide onboarding related functionality. The scenario will be automatically installed as a dependency along with other onboarding scenarios; it should never be installed on its own.
The im_corp_onboard component does not exist in version 12.4 or 12.5. Suggest this is made into a version variant from when it last appears. - Siobhan
hid_first_login
Purpose:
This scenario provides all the configuration necessary to deploy a "first login" experience for newly onboarded users – or users accessing the system for the first time. As its prefix suggests, this component can be installed in both Bravura Pass and Bravura Identity instances. Depending on the type of information available, the scenario allows new users to authenticate into the product’s portal by using some alternate authentication factors such as PII information or a PIN sent to their email address or their cell phone via SMS. Once authenticated, they have the option to register security questions, their mobile device and set an initial password on their accounts. The hid_first_login scenario is often installed alongside other onboarding scenarios in order to streamline the user onboarding experience and reduce the amount of manual work required for post-onboarding tasks.
Configuration:
When installed, this scenario adds a number of new authentication chains to the product instance. External data store (extdb) tables containing configuration relevant to this scenario:
hid_authchain_select: Adds authentication chains rules to allow users logging in for the first time to authenticate using an alternate factor, such values of their PII attributes or a PIN sent to their mailbox or mobile device via SMS. Where PII attributes are used, they are collected during onboarding and then discarded once the user has used them during authentication.
im_corp_passgen
Purpose:
A supporting (dependency) scenario for other onboarding scenarios, it implements a password generation plugin for new accounts using the default password policy configured for the instance. Without this, requesters would be prompted to enter an initial password for new accounts and automated onboarding requests would fail.
hid_profileid
Purpose:
Another scenario typically installed alongside other onboarding scenarios, it generates an attribute called PROFILEID when attribute validation is run as part of onboarding requests. This attribute can then be referenced to reliably determine the profile ID for a user, even if their profile has not yet been created during onboarding requests.
Configuration:
External data store (extdb) tables containing configuration relevant to this scenario:
hid_global_configuration: under the PDR setting, add or edit the comma-separated list of the IDs of the PDRs for which this Scenario has to work
hid_policy_attrval_*: Adds rules for the setting the PROFILEID attribute based on the FIRST_NAME, LAST_NAME and OTHER_NAME profile attributes.