Prerequisites for Creating a Connection

You must satisfy the following prerequisites to create a connection with the SOAP Adapter.

Accessible WSDL

Ensure that the WSDL to use is reachable. There is no restriction on the type of WSDL to use.

See Support for Uploading a WSDL with Schemas in a ZIP File and Support for Multiple Part Messages in Document-Style WSDLs.

OAuth Security Policies Use

If you are using one of the OAuth security policies, you must already have registered your client application to complete the necessary fields on the Connections page. The Basic Authentication and No Security Policy security policies are exempted.

Before a client application can request access to resources on a resource server, the client application must first register with the authorization server associated with the resource server.

The registration is typically a one-time task. Once registered, the registration remains valid, unless the client application registration is revoked.

At registration time, the client application is assigned a client ID and a client secret (password) by the authorization server. The client ID and secret are unique to the client application on that authorization server. If a client application registers with multiple authorization servers (for example, Facebook, Twitter, and Google), each authorization server issues its own unique client ID to the client application.

@ref: http://tutorials.jenkov.com/oauth2/authorization.html

For OAuth configuration, read the provider documentation carefully and provide the relevant values.

JWT Assertions Outbound Use

Perform the following prerequisites to use JWT assertions.
  • Manually create a signing key for upload on the Certificates page. See Upload a Certificate to Connect with External Services.

    The service provider typically provides instructions on how to generate the signing keys and the format. For an example, see Required Keys and OCIDs.

  • Create the JWT header and JWT payload JSON files. You upload both files on the Connections page when configuring the SOAP Adapter to support JWT assertions.

    For example:

    Note the following details about the JWT payload JSON file:
    • The iss, exp, sub, and aud claims are mandatory.​ Oracle Integration validates that these claims are present. Anything else you upload depends on the provider you are trying to call. For example, NHS may require additional claims.
    • The iat (issued at), exp (expiry), nbf (not before), and jti (JWT ID) claims are dynamically calculated if present in the JWT payload JSON file. If you manually provide values for these claims, they are replaced with dynamically-calculated values.
    • Any remaining claims are optional and depend upon the provider you are calling.
    JWT Header JSON File Example JWT Payload JSON File Example 
    {
    "alg" : "RS256",
    "typ": "JWT",
    "kid": "fajwt2"
}

    Where:

    • alg: The algorithm to use.
    • typ: A JWT assertion typically set to JWT.
    • kid: A key identifier that is uniquely-generated and associated with the uploaded signing key. 
    {
    "iss": "f6c9d437eed64e2a8f2b045e39e2e03f",
    "sub": "admin.user",
    "aud": "https://identity.oraclecloud.com/",
    "exp": "1739412427"
    "iat": "1727372629"
    "jti": "12345"
  }

    Where:

    • JWT issuer (iss): A unique identifier for the entity that issued the assertion. This is typically the entity that holds the key material used to sign or integrity-protect the assertion. Examples of issuers are OAuth clients (when assertions are self-issued) and third-party security token services. If the assertion is self-issued, the issuer value is the client identifier (client_id). If the assertion was issued by a security token service (STS), the issuer must identify the STS in a manner recognized by the authorization server. The assertion must contain an issuer.
    • JWT subject (sub): The subject typically identifies an authorized accessor for which the access token is being requested (that is, the resource owner or an authorized delegate). In some cases, this may be a pseudo anonymous identifier or other value denoting an anonymous user. When the client is acting on behalf of itself, the subject must be the value of the client's client_id. The assertion must contain a subject.
    • JWT audience (aud): A value that identifies the party or parties to process the assertion. The assertion must contain an audience that identifies the authorization server as the intended audience. The authorization server must reject any assertion that does not contain its own identity as the intended audience (in this case, for an Oracle Cloud Infrastructure Identity and Access Management identity domain, https://identity.oraclecloud.com/).
    • Expires at (exp): The time at which the assertion expires. While the serialization may differ by assertion format, the time must be expressed in UTC format with no time zone component. The assertion must contain an expires-at entity that limits the window during which the assertion can be used. The authorization server must reject expired assertions (subject to allowable clock skew between systems). The authorization server may reject assertions with an expires-at attribute value that is unreasonably far in the future.
    • Issued at (iat): The time at which the JWT was issued.
    • JWT identifier (jti): A unique identifier for the JWT. This helps to prevent replay attacks and ensures the token is only used once.

  • Note:

    Carefully review the JWT documentation of your service provider and ensure that you follow all guidelines required by the service provider to correctly create the header and payload files. The content of each file varies from one service provider to another. The SOAP Adapter supports the different implementations of JWT provided by the following service providers: