--- title: Configuration Provider node description: The Configuration Provider node is a scripted node that dynamically imitates another node and replaces it in the journey. component: auth-node-ref version: latest page_id: auth-node-ref::config-provider canonical_url: https://docs.pingidentity.com/auth-node-ref/latest/config-provider.html keywords: ["Nodes & Trees", "Journeys", "Authentication", "Scripts"] page_aliases: ["auth-node-config-provider.adoc"] superseded_by: https://docs.pingidentity.com/auth-node-ref/latest/config-provider.html section_ids: config-provider-examples: Examples example_1_imitate_the_message_node: "Example 1: Imitate the Message node" example2: "Example 2: Imitate the Set Success Details node" example3: "Example 3: Imitate the Email Suspend node" availability: Availability inputs: Inputs config-provider-dependencies: Dependencies decide-node-type: Choose the type of node to imitate get-template-script: Get a template script create-script: Configure the script configuration: Configuration outputs: Outputs callbacks: Callbacks outcomes: Outcomes errors: Errors --- # Configuration Provider node The Configuration Provider node is a scripted node that dynamically imitates another node and replaces it in the journey. The script builds a map of configuration properties matching settings for the imitated node. The Configuration Provider node uses the settings to imitate the other node. ## Examples ### Example 1: Imitate the Message node In the following example, the Configuration Provider node imitates a [Message node](message.html). The Configuration Provider settings are the following: * Script A script to configure a [Message node](message.html) dynamically. The script assigns values to the [required properties](#get-template-script), accessing the `username` from shared state data to set the message: ```json config = { "message": {"en-GB": `Hi ${nodeState.get("username")}. Please confirm you are over 18.`}, "messageYes": {"en-GB": "Confirm"}, "messageNo": {"en-GB": "Deny"}, "stateField" : null } ``` * Node Type `Message Node` * Script Inputs `username` The default, `*`, also works because `username` is one of the available shared state properties. The Configuration Provider node is part of a journey where the user enters their username and password before getting the message screen, so their username is in the shared state data. Notice the outcomes of the node include those of the [Message node](message.html) (True, False): ![Journey with a \[.label\]#Configuration Provider# node](_images/config-provider-journey.png) When the journey reaches the Configuration Provider node, the script for the node retrieves the `username` and dynamically configures the node. The Configuration Provider node, imitating a [Message node](message.html), prompts the user with the message: ![A \[.label\]#Configuration Provider# node imitating a \[.label\]#Message# node](_images/config-provider-example.png) * When the user clicks Confirm, the journey continues to the [Increment Login Count node](increment-login-count.html). * When the user clicks Deny, the journey continues to the [Failure node](failure.html). * If the configuration process fails, the node triggers the Configuration failure outcome and the journey continues to the [Failure node](failure.html). In this case, you can find the reason for the failure in the logs. ### Example 2: Imitate the Set Success Details node This example uses the Configuration Provider node to imitate a [Set Success Details node](set-success-details.html) and add the following additional details to the JSON response: * A dynamic `apiResponse` field, which returns the response from the `monitoring/health` endpoint. * A static `authMethod:password` field. * A `universalId` session property, which returns the corresponding value from the session when the user authenticates. ![Journey with a \[.label\]#Configuration Provider# node imitating the \[.label\]#Set Success Details# node](_images/set-success-details-journey-dynamic.png) * The [Page node](page.html) containing the [Platform Username node](platform-username.html) and [Platform Password node](platform-password.html) prompts for credentials. * The [Data Store Decision node](data-store-decision.html) validates the username-password credentials. * The [Increment Login Count node](increment-login-count.html) updates the number of successful authentications in the user profile. * The Configuration Provider node, imitating a [Set Success Details node](set-success-details.html), adds the additional configured details to the JSON response upon successful authentication. This example uses the following configuration: * Script The following next-generation script calls the `monitoring/health` endpoint and dynamically configures the node by setting the [required properties](#get-template-script). It includes the API response in the JSON response if authentication is successful along with the static field and session property: ```javascript var requestAPI = "https://example.com/monitoring/health"; var response = httpClient.send(requestAPI).get(); var apiResponse = response.json(); config = { "successDetails": { "authMethod": "password", "apiResponse": apiResponse }, "sessionProperties": { "universalId": "sun.am.UniversalIdentifier" } }; ``` * Node Type `Set Success Details` * Script Inputs `*` When the user authenticates successfully using this journey, the JSON response includes the additional details you configured. For example: ```json { "tokenId": "AQIC5wM…​TU3OQ*", "successUrl": "/enduser/?realm=/alpha", "realm": "/alpha", "universalId": "id=bjensen,ou=user,o=alpha,ou=services,ou=am-config", "apiResponse": { "status": "OK" }, "authMethod": "password" } ``` ### Example 3: Imitate the Email Suspend node This example extends the default `resetPassword` journey to include the user's email address in the email suspend message. This is achieved by using the Configuration Provider node to imitate the [Email Suspend node](email-suspend.html). ![Journey with a \[.label\]#Configuration Provider# node imitating the \[.label\]#Email Suspend# node](_images/email-suspend-journey-dynamic.png) The Configuration Provider node in this example uses the following configuration: * Script The following next-generation script dynamically configures the node by setting the [required properties](#get-template-script). It retrieves the user's email address from the shared state and includes it in the email suspend message: ```javascript var attributes = nodeState.getObject("objectAttributes"); config = { "emailTemplateName" : "resetPassword", "emailAttribute" : "mail", "emailSuspendMessage" : { "en" : `An email has been sent to ${attributes.get("mail")}. Click the link in that email to reset your password.` }, "objectLookup" : true, "identityAttribute" : "mail" }; ``` * Node Type `Email Suspend Node` * Script Inputs `*` When the journey is suspended, the updated suspend message is shown. For example: ![Suspend message including email address](_images/dynamic-email-suspend-message.png) ## Availability | Product | Available? | | ------------------------------------- | ---------- | | PingOne Advanced Identity Cloud | Yes | | PingAM (self-managed) | Yes | | Ping Identity Platform (self-managed) | Yes | ## Inputs The specific shared state inputs depend on your script and the configuration it builds. The shared state data must include all required Script Inputs properties. In other words, shared state data must include whatever the Script requires to prepare configuration data for the imitated node. ## Dependencies To use this node, you need to prepare a script that provides values for the settings of the imitated node. 1. [Choose the type of node to imitate](#decide-node-type) 2. [Get a template script](#get-template-script) 3. [Configure the script](#create-script) ### Choose the type of node to imitate The imitated node must have a *defined set of outcomes*. This can be a variable set of outcomes from a predefined list, such as the [Polling Wait node](polling-wait.html), or a fixed set of outcomes, such as the [Message node](message.html). You can't use a node type whose outcomes are defined *entirely* by configuration, such as the [Scripted Decision node](scripted-decision.html). ### Get a template script Create a template script using the script editor in the node configuration. 1. Set the Node Type in the node configuration. 2. Select a valid version of the node to imitate. 3. In the Script field, click [icon: chevron-down, set=fa]to display the list of scripts, and then click [icon: plus, set=fa]to open a script editor. 4. Select Next Generation as the scripting engine and click Next. The editor displays a template script with all the required properties. For example, the Polling Wait node generates the following script: ```json config = { "secondsToWait" : 8, "spamDetectionEnabled" : false, "spamDetectionTolerance" : 3, "waitingMessage" : { }, "exitable" : false, "exitMessage" : { } }; ``` If you haven't selected a node type, you'll get an empty script. ### Configure the script Configure your script to set values for all the required node properties. 1. Use the [imitated node's properties](#get-template-script) to generate a template next-generation script. The node can also use the legacy script engine, but the UI won't generate a template of the properties. Your script must have a `config` object. This object must define the configuration properties that match the settings of the imitated node. For example, a script for the [Email Suspend node](email-suspend.html) has the following structure: ```json config = { "emailTemplateName" : "registration", "emailAttribute" : "mail", "emailSuspendMessage" : { "en" : "An email has been sent to the address you entered. Click the link in that email to proceed." }, "objectLookup" : false, "identityAttribute" : "userName" }; ``` 2. Set the values of the configuration properties as required. Learn about the node bindings in the `config-provider-node.js` sample script. You can also find more information about the common bindings in the [scripting API](https://docs.pingidentity.com/pingoneaic/am-scripting/script-bindings.html). Use these to help you set the values of the configuration properties. Refer to [example 3](#example3) for a script that uses shared state data to set the node configuration. 3. Save your script, and select it from the list when you configure the node's Script property. ## Configuration | Property | Usage | | ------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Node Type | Select the [type of node to imitate](#decide-node-type). The list is restricted to node types with outcomes that are fixed or variable based on predefined values. | | Node Version | Select the version of the node to imitate.Default: The latest available version of the selected node. | | Script | Select the script you [created for this node](#config-provider-dependencies). The list displays legacy and next-generation Configuration Provider scripts.To create a new script, click [icon: plus, set=fa]to open a script editor. The editor generates a [template script](#get-template-script) for you based on the selected node type. | | Script Inputs | Optionally, limit the shared state data properties in the shared state input to the selected Script.Default: `*` (Any available shared state property) | ## Outputs The outputs match those of the imitated node. ## Callbacks The callbacks sent match those of the imitated node. ## Outcomes The Configuration Provider node inherits the outcomes of its configured Node Type. Connect these as you would the outcomes of the imitated node. Nodes with a variable set of outcomes inherit all the possible outcomes even if runtime configuration makes them unreachable. Connect these outcomes to the [Failure node](failure.html). This node also has a Configuration failure outcome. The Configuration failure outcome arises when: * The Configuration Provider node failed to build the configuration map. * The configuration map is missing required values. * The configuration map is invalid. ## Errors In addition to the messages from the imitated node, this node can log the following: * Warnings * `Failed to collect inputs of contained node: node-type` A required input property was missing. * `Failed to get outcome provider for node type.` The Node Type outcomes were missing. * Errors * `Failed to configure node: node-type` This corresponds to the Configuration failure outcome. To troubleshoot HTTP errors this node causes, refer to the *Errors* section of the imitated node.