Securing SOAP Web Services
Adeptia allows you to apply security policies to SOAP web services, controlling how messages are authenticated, signed, encrypted, and validated as they flow between systems.
What security policies do
A security policy is a reusable configuration object that you attach to a SOAP web service provider. Once attached, the policy governs what security measures are applied to outgoing messages your service sends and what requirements incoming messages must satisfy before they are accepted. This lets you enforce consistent security rules across integrations without embedding security logic into individual flows.
Authentication options
When a SOAP web service requires callers to prove their identity before it processes a request, you configure the authentication approach in the security policy. Adeptia supports the following authentication types for incoming requests:
| Authentication type | How it works |
|---|---|
| Basic authentication | The caller supplies a username and password, which Adeptia validates against a configured credential store |
| Kerberos authentication | The caller presents a Kerberos/SPNEGO token; Adeptia validates it using a configured login module and makes the authenticated principal available to the integration flow |
For basic authentication, you choose how incoming credentials are verified:
| Verification mode | Description |
|---|---|
| Fixed username and password | Credentials are checked against a specific username and password stored in the security policy |
| Adeptia user store | Credentials are checked against Adeptia's own user directory, optionally restricted to specific groups or roles |
| LDAP directory | Credentials are checked against an external LDAP directory, optionally restricted to specific groups |
Message-level security
Beyond transport-level authentication, Adeptia supports WS-Security controls that operate at the SOAP message level. You can enable any combination of the following for outgoing and incoming messages:
| Security feature | What it provides |
|---|---|
| Digital signature | Proves the message originated from a trusted source and has not been altered in transit |
| Encryption | Protects message content so only the intended recipient can read it |
| Username token | Embeds a username and password directly in the SOAP message header, with support for plain-text or digest password formats and optional nonce and timestamp elements |
| Timestamp | Adds a time-to-live value to the message to prevent replay attacks |
For both signature and encryption, you select a keystore and an alias that identify which certificate or key to use. You can also specify which parts of the message body are signed or encrypted, giving you fine-grained control over what is protected.
Outgoing message security
When Adeptia sends a SOAP message, the security policy controls which security elements are added and in what order. You define the sequence of operations, for example applying a timestamp first, then a username token, then a signature, then encryption.
Incoming message validation
When Adeptia receives a SOAP message, the security policy defines what security elements must be present and valid. If a required signature or encryption element is missing or covers unexpected parts of the message, the request is rejected. You configure separate keystores for decryption and signature verification on incoming messages, and you specify the expected password type for incoming username tokens.
WS-Addressing support
Adeptia can read WS-Addressing headers from incoming SOAP requests, such as the action, message identifier, reply-to address, fault-to address, and related message references. These values are made available to your integration flow. On outgoing responses, Adeptia can add WS-Addressing headers based on values you configure in the web service provider.
Attachment handling
SOAP messages may carry binary attachments alongside the XML body. Adeptia identifies and downloads these attachments as part of processing an incoming request, making the attachment path and filenames available to the integration flow. When sending a response, Adeptia can attach files to the outgoing SOAP message using MIME packaging.
SOAP version support
Adeptia detects whether an incoming request uses SOAP 1.1 or SOAP 1.2 based on the content type of the request and processes it accordingly.
Keystore and truststore configuration
Signature and encryption operations rely on keystores that you manage separately in Adeptia and then reference from the security policy. You select the appropriate keystore and alias for each operation: signing outgoing messages, encrypting outgoing messages, verifying signatures on incoming messages, and decrypting incoming messages.
Runtime overrides
Security policy settings such as the user credentials, truststore, and keystore can be overridden at runtime using values from the integration flow's context. This allows a single security policy to adapt to different environments or trading partners without requiring separate policy definitions for each scenario.