Thales Configuration

The Thales OneWelcome Authorizer enables secure, dynamic token enrichment through webhook-based integration. It supports both OIDC and SAML flows and introduces the following capabilities.

Successful implementation depends on validating webhook contracts and aligning with Thales-specific behavior for payload structure, response handling, and error management.

Configuration steps depend on the Thales OneWelcome admin interface.

Defining the Webhook

Configure one of the following webhooks:

• Access Token Webhook
• SAML Assertion Webhook

PlainID Endpoint Configuration

Endpoint Structure

POST /idp-hook/thales/{flow}

Where {flow} can be one of the following values:

• access-token
• saml-assertion

Request Handling

Headers

JWT Validation

PlainID must validate the incoming token before processing the request.

To validate the JWT:

1. Extract the JWT from the Authorization header.

2. Decode the token and read the iss claim.

3. Retrieve the OpenID configuration from:

   {iss}/.well-known/openid-configuration
   

4. Extract the jwks_uri value.

5. Validate the token signature by using the JWKS.

6. Validate the token claims:

   • Default client_id is onewelcomeAccessWebHookClient.
   • scope must start with onewelcome_webhooks.
   • The token must not be expired.

Example JWT Payload

{
  "aud": "https://webhook-test.com/...",
  "sub": "onewelcomeAccessWebHookClient",
  "scope": "onewelcome_webhooks onewelcome_webhook_jan",
  "iss": "https://playground2.gw.test.onewelcome.net/oauth",
  "exp": 1768297733,
  "client_id": "onewelcomeAccessWebHookClient"
}

Thales-Specific PlainID Configuration

The following configuration is required for Thales OneWelcome integrations:

idpConfig:
  useIncomingJWTForPDP: true
  expectedClientID: onewelcomeAccessWebHookClient
  scopePrefix: onewelcome_webhooks

idToken:
  verify: true
  iss: https://{{address}}.onewelcome.net/oauth
  aud: https://{{address}}/idp-hook/1.0/thales/access-token

identityAttributes:
  - name: firstName
    path: $.firstName

Configuration Notes

idToken configuration already exists in the platform and should not be duplicated unless customization is required.

Request Payload

The request payload structure depends on the webhook type configured in Thales OneWelcome.

Access Token Webhook Example

{
  "userClaims": {
    "firstName": "John"
  }
}

SAML Assertion Webhook Example

{
  "userAttributes": {
    "firstName": "John"
  }
}

Thales Request Attribute Mapping

In Thales OneWelcome, user-related Attributes are sent differently depending on the integration type:

The JSONPath for each Attribute must be configured and included in the request so PlainID can extract and evaluate the relevant values.

Example Attribute Mapping

identityAttributes:
  - name: firstName
    path: $.firstName

In this example:

• name defines the Attribute name used by PlainID.
• path defines the JSONPath location within the incoming Thales request payload.

PlainID resolves the configured JSONPath and injects the Attribute into the Policy evaluation context.

Generic Request Structure

The exact request payload structure from Thales should be validated against the official documentation before production deployment.

Assumed Structure

{
  "user": { ... },
  "client": { ... },
  "context": { ... },
  "tokenType": "access_token | saml_assertion"
}

Request Payload Parameters

user Object

client Object

context Object

Response Format

PlainID returns authorization claims to be injected into the token or assertion.

Example Response

{
  "claimPortalRole": ["Administrator"],
  "DepartmentManagerLevel": ["Senior"]
}

Response Behavior

• Each key-value pair is added as a claim.

• Claims are included in one of the following outputs:

  • Access Token for OIDC flows.
  • SAML Assertion for SAML flows.

Error Handling

Use the following recommended behavior:

Thales fallback behavior must be confirmed before production deployment.