Connection and Source

Specify the required connection details to connect to the attribute source/remote service.

The content displayed within the Connection section (for Table, SQL, and LDAP) and the Source section (for HTTP and Parsers) depends on the attribute connector type. Use the tabs below to see the steps for the appropriate type:

Table

1. In the Driver dropdown, use the Search... field to filter the list and select the driver required for your database connection.

   If the required driver is not listed, type the complete driver class name and click + Add "...".

   note

   The driver specifies the class name of the JDBC driver.

2. In Connection URL, enter a valid JDBC URL to access the database.

   For example: jdbc:oracle:thin:@//localhost:1521/my-instance

3. Click Add to finalize your attribute connector configuration.

SQL

1. In the Driver dropdown, use the Search... field to filter the list and select the driver required for your SQL database connection.

   If the required driver is not listed, type the complete driver class name and click + Add "...".

   note

   The driver specifies the class name of the JDBC driver.

2. In Connection URL, enter a valid JDBC URL to access the SQL database.

   For example: jdbc:oracle:thin:@//localhost:1521/my-instance

3. Click Add to finalize your attribute connector configuration.

LDAP

1. From the Factory initial dropdown, select the fully qualified class name that will create the initial context for the LDAP service provider.

   note

   Use the com.sun.jndi.ldap.LdapCtxFactory value to select the Oracle JNDI LDAP provider.

2. In Connection URL, enter the LDAP URL of the LDAP Attribute Source.

   LDAP URLs are typically specified as follows:

   Type	URL	Port
   plaintext	ldap://<host>:<port>	389
   secured by TLS	ldaps://<host>:<port>	636

   Important

   This field must contain a unique URL address using the character set defined in RFC 1738 to a maximum length of 255 characters.

3. From the Authentication dropdown, select the authentication type to be used by the LDAP server.

   The following options are available:

   • simple - The LDAP server utilizes simple authentication. This option requires setting two additional fields.
     • Principal - Enter the security principal to be used for the LDAP server's authentication.
     • Password - Enter the password that is required for the LDAP server's authentication.
   • none - The LDAP server does not utilize any authentication. In this option, no additional authentication fields are required.

4. Click Add to finalize your attribute connector configuration.

HTTP

1. In the URL field, enter the endpoint URL of the remote service you want to connect to.

   This URL is the main endpoint where the HTTP Attribute Connector will send requests to retrieve or send data. Ensure it’s correctly formatted, including any required parameters.

   note

   If the URL includes placeholders like {0}, users can select key attributes from a dropdown to dynamically assign values to these placeholders. For example, https://nominatim.openstreetmap.org/?addressdetails=1&q={0}&format=json&limit=1 allows {0} in the q parameter to be replaced with a selected attribute. Multiple placeholders can be used (e.g., {0}, {1}), each receiving a different selected value.

2. From the Method dropdown, select the HTTP method to use for the request.

   The available options are:

   • GET
   • POST

   The default option is POST.

3. To add custom HTTP headers, click Add header. Headers can be one of two types:

   • Static: Requires you to specify the Header value to be used.
   • Dynamic: Requires you to select a Header key attribute that will provide the header value dynamically.

4. To allow connections using insecure TLS, check the Allow insecure TLS option.

   Enabling this option allows the connector to communicate over TLS, even if the certificate is not trusted. Use this only if necessary, as it may expose the connection to security risks.

5. Check Process URL to enable URL processing.

   This option allows for advanced processing on the URL. It should be enabled only if specific URL modifications are required during the request process.

6. Optionally, under Keystore & Truststore, add any necessary SSL/TLS certificates required for secure connections:

   • Click Add Keystore and enter:
     • the path to the Keystore file
     • the Keystore type, typically JKS
     • the Keystore password
   • Click Add Truststore and enter:
     • the path to the Truststore file
     • the Truststore type, typically JKS
     • the Truststore password

7. Under HTTP Response Codes, enter any Accepted codes and Ignored codes.

   • Accepted codes: A comma-separated list of HTTP status codes that indicate a successful response, besides 200, which is always accepted.

     The attribute connector will return the body of any HTTP response that has one of the accepted status codes. If the status code is not on the list, the connector will either ignore the response or fail.

   • Ignored codes: A comma-separated list of HTTP status codes that indicate an unsuccessful response, but should be ignored to allow the connector to proceed even if they are returned.

     If an HTTP response status code is unsuccessful and is included in the list of ignored codes, the attribute connector will return an empty value for the relevant attribute, rather than throwing an error.

   • Toggle Detailed exception to True to enable detailed logging of exceptions that happen during a request. Enabling this option provides more in-depth logging, which is useful for debugging and analyzing request and response details during exceptions.

9. Select the authentication type for the request under Authentication mode,

   Choose an appropriate authentication method that meets the endpoint’s requirements. Depending to your selection, additional fields will appear:

   Basic

   Add a username and a password in the respective fields.

   Bearer

   Provide a token for the bearer authentication under the Token field.

   OAuth2

   1. Select an OAuth mode from the Token service authentication mode dropdown.

      This specifies the authentication mode that will be used when retrieving access tokens.

   2. Enter the Client ID and Client Secret. These values authenticate the client application to the authorization server to retrieve OAuth access tokens.

   3. Enter the Token URL, which is the endpoint where the connector can retrieve the access token.

   4. Optionally, specify a Scope. This limits the access granted by the token, depending on the permissions needed by the endpoint.

10. Under Retry strategy, click Add strategy if you want to define how the connector handles failed requests.

    Specify the retry parameters that appear when this option is selected:

11. In the Max retries field, enter the maximum number of retry attempts.

    This field specifies how many times the connector should attempt to retry the request if it fails. Setting a limit prevents endless retry loops and helps control request behavior in case of errors.

12. In Max time for retries (ms), enter the maximum amount of time, in milliseconds, for all retry attempts combined.

    This value limits the total duration for retrying requests. If this time limit is reached, the connector will stop retrying, regardless of the number of remaining attempts. For more details, refer to the HTTP attribute connector documentation.

13. From the Interval type dropdown, select the type of delay between retries.

    • Fixed: The delay between retries remains consistent.

    • Exponential: The delay increases exponentially with each retry attempt, allowing more time between consecutive retries.

      When you select the Exponential interval type, an additional Factor field appears, allowing you to set a factor that determines how the interval increases. The factor is essentially the exponent used in calculating the interval.

14. In Interval (ms), specify the delay duration, in milliseconds, for retries based on the interval type chosen.

    For Fixed intervals, this is the constant wait time between retries. For Exponential intervals, this is the base value that increases progressively with each retry attempt.

15. Under Retriable codes, enter the HTTP status codes that should trigger a retry.

    • List the HTTP status codes that, if encountered, will prompt the connector to retry the request. For example, entering 503 (Service Unavailable) will trigger a retry if the service temporarily fails.

16. Click Add exception type to define additional conditions that prompt the connector to retry, providing finer control over retry behavior.

    • Enter the Exception type that triggers a retry. Optionally, restrict the retry only to cases where the message contains the string specified in Exception message.

17. Click Add to finalize your attribute connector configuration.

XML parser

1. From the Source dropdown, select the source type of the XML data to be processed:

   • Key attribute: the value of an attribute provided dynamically for each individual policy evaluation.

     Select the appropriate key attribute from the Key attribute dropdown.

   • Literal: a literal XML value embedded in the configuration which remains constant for all policy evaluations.

     Provide the XML value in the XML Payload field.

   • File: the contents of a file within the environment which remains constant for all policy evaluations.

     Enter the path to the file in the File path field.

2. Optionally, select the Base64 encoded checkbox if the source content is base64-encoded instead of plain text.

3. Click Add to finalize your attribute connector configuration.

JSON parser

1. From the Source dropdown, select the source type of the JSON data to be processed:

   • Key attribute: the value of an attribute provided dynamically for each individual policy evaluation.

     Select the appropriate key attribute from the Key attribute dropdown.

   • Literal: a literal JSON value embedded in the configuration which remains constant for all policy evaluations.

     Provide the JSON value in the JSON Payload field.

   • File: the contents of a file within the environment which remains constant for all policy evaluations.

     Enter the path to the file in the File path field.

2. Optionally, select the Base64 encoded checkbox if the source content is base64-encoded instead of plain text.

3. Click Add to finalize your attribute connector configuration.

JWT parser

1. From the Source dropdown, select the source type of the JWT value to be processed:

   • Key attribute: the value of an attribute provided dynamically for each individual policy evaluation.

     Select the appropriate key attribute from the Key attribute dropdown.

   • Literal: a literal token value embedded in the configuration which remains constant for all policy evaluations.

     Provide the JWT value in the Token field.

   • File: the contents of a file within the environment which remains constant for all policy evaluations.

     Enter the path to the file in the File path field.

2. Under the Signature tab, specify the source of the cryptographic key to be used for verification in the Signature source field:

   • File: a file within the environment containing the signature key.

     Enter the path to the file in the File path field.

     Optionally, select one or both of the Signature validation checkboxes analyzed in the table below.

   • Literal: a literal key embedded in the configuration.

     Provide the cryptographic key in JWK or PEM format in the Literal signature key field.

     Optionally, select one or both of the Signature validation checkboxes analyzed in the table below.

   • None: no signature key required.

     You must select one of the Signature validation checkboxes analyzed in the table below.

   Checkbox	Description
   Allow unsecured tokens	Accepts tokens lacking a digital signature (JWS) with a signature algorithm value set to {"alg":"none"}. This configuration aligns with the purpose of unsecured tokens, as defined in the specification RFC 7519, Section 6. For the Authorization Hub, the unsecured JWT is embedded in a container whose contents have been validated already by the PEP. If the PEP is trusted, then it can alternatively send the claims as individual attributes or as a single attribute containing the plain JSON payload.
   Skip signature validation	JWT signature verification is explicitly disabled. IMPORTANT: This option is unsuitable for secure production environments.

3. Under the Assertions tab, enable additional checks on token claims to verify the token validity:

   • Not expired: Ensures that the token isn't expired - exp claim

     If needed, set the allowed Clock skew to account for potential time differences between servers.

   • Not before: Ensures that the token isn't used before its activation time - nbf claim

     If needed, set the allowed Clock skew to account for potential time differences between servers.

   • Trusted authority: Checks if the iss claim matches one or more expected issuers.

     1. Set the expected issuer in the Trusted issuer field.
     2. If needed, click Add issuer to add more trusted issuers.

   • Specific audience: Ensures that the aud claim matches the expected audience.

     1. Set the expected audience in the Audience field.
     2. If needed, click Add audience to add more trusted issuers.
   tip

   Each assertion targets a specific claim. If the corresponding claim is missing, the token is considered invalid. Mark an assertion as Optional if you want it checked only when its corresponding claim is present, and ignored otherwise.

4. Click Add to finalize your attribute connector configuration.

After clicking Add, the system checks your configuration for issues. If the validation is successful, then you return to the attribute connectors list. Otherwise, the faulty sections are marked in red along with the corresponding fields. In order to save your configuration successfully, you should fix all issues found by the system and click Add again.