0 / 0
Security page of the REST step in DataStage

Security page of the REST step in DataStage

On the Security page of the REST step, you can specify the security details of the REST web service.

You must specify values for the following fields to configure security settings for the REST web service.
Authentication
Select the type of authentication to use for the REST web service.
Basic
Uses the HTTP Basic authentication mechanism that is specified in the RFC2617. When the Basic option is selected, you must provide a valid username and password to access the content. You can also specify a realm, which defines a protected space that identifies valid users of a web application by associating each username with a password and role. You need to select the encoding type of the user credentials that the REST service is configured to accept for the Basic authentication.
Digest
Uses the HTTP Digest authentication mechanism that is specified in the RFC2617. When the Digest option is selected, you must provide a valid username and password to access the content. You can also specify a realm. You need to select the encoding type of the user credentials that the REST service is configured to accept for the Digest authentication.
LTPA
Is the IBM Lightweight Third-Party Authentication mechanism. The application server sends a session cookie to the browser that contains an LTPA token after the user is authenticated. This LTPA token is used for a single session. When the LTPA option is selected, user must provide a valid username and a password to access the content. You can also specify a realm. You also need to select the encoding type of the user credentials that the REST service is configured to accept for the LTPA authentication.

Select Use LTPA cookie from input to use the LTPA cookie from the previous REST step. If you select this option, on the Mappings page, you must map the LTPA cookie to the output cookie from the previous REST step.

Select Send LTPA cookie to output to create an LTPA cookie element in the output schema that can be used in the next REST step. For further connections, you can use the LTPA cookie instead of specifying credentials.

For example, suppose that in REST step 1 you specify a username and password for LTPA. If you select Send LTPA cookie to output, the REST step creates an LTPA cookie element in the output schema that can be used in the next REST step. In REST step 2, you can configure the REST service with LTPA without specifying user credentials by selecting Use LTPA cookie from input. On the Mappings page, you must then map the LTPA cookie to the input value from REST step 1.

OAuth2 Bearer
Helps access the protected resource on behalf of a resource owner by providing a bearer token. A bearer token is a security token that was issued to the client by an authorization server. When a bearer token is specified, you do not need to specify a username and password to access the resource.

Select Use authorization from input to use the bearer token value from the previous REST step. The authorization header is created on the Mappings page. You must map the authorization header to the bearer token value from the previous REST step.

Enable SSL
Uses the Secure Socket Layer (SSL) protocol to encrypt the data that is sent between the client and the server. The SSL protocol supports hostname verification, which ensures that the hostname in the URL to which the client connects matches the common name in the server SSL certificate before the SSL connection is made. If the REST client is intended to accept the self-signed certificates, then you need to select Accept self-signed certificates. The SSL protocol also supports both SSL server and client authentications by providing the keystore and truststore files for the REST service that is configured.
Generative AI search and answer
These answers are generated by a large language model in watsonx.ai based on content from the product documentation. Learn more