Creating an Endpoint Alias for a Provider Web Service Descriptor for Use with HTTP/S

SOA Governance and API Management : Administering Integration Server : Configuring Endpoint Aliases for Web Services : Creating an Endpoint Alias for a Provider Web Service Descriptor for Use with HTTP/S

When creating a web service endpoint alias for provider web service descriptor that uses an HTTP/S binder, you need to supply information that falls into the following categories:

Web Service Endpoint Alias. Endpoint name, description, and transport type.

HTTP/S Transport Properties. Server on which the web service resides.

WS Security Properties. Information the SOAP processor needs to decrypt and verify the inbound SOAP request and/or encrypt and sign the outbound SOAP response and the details for adding the timestamp information.

Note:

WS-Security credentials such as private keys and public keys do not always need to be provided in a web service endpoint alias. If this information is not provided in the alias, Integration Server can obtain the information from other locations. For more information about usage and resolution order of certificates and keys for WS-Security, see the Web Services Developer’s Guide.

Message Addressing Properties. WS-Addressing information that Integration Server uses to generate the WS-Addressing headers of the SOAP requests and responses. This includes the destination address of a message or fault and the authentication credentials required to send a response to a different address than the one from which request was received.

Reliable Messaging Properties. Reliable messaging information specific to the web service endpoint. By default, Integration Server applies the reliable messaging configuration defined on the Settings > Web Services > Reliable Messaging > Edit Configuration page to all web service providers and consumers. If you want to override the server-level reliable messaging configuration for a specific web service provider or consumer, define reliable messaging properties for the associated web service endpoint alias.

To create a WS provider web service endpoint alias for use with HTTP/S

1. Open Integration Server Administrator if it is not already open.

2. In the Navigation panel, select Settings > Web Services.

3. Click Create Web Service Endpoint Alias.

4. Under Web Service Endpoint Alias Properties, provide the following information:

In this field...	Specify...
Alias	A name for the provider web service endpoint alias. The alias name cannot include the following illegal characters: # ©\ & @ ^ ! % * : $ . / \ \ ` ; , ~ + = ) ( \| } { ] [ > < "
Description	A description for the endpoint alias.
Type	Provider
Transport Type	Specify the transport protocol used to access the web service. Select one of the following: HTTP HTTPS

5. Under TransportType Transport Properties, provide the following information:

In this field...	Specify...
Host Name or IP Address	Host name or IP address of the Integration Server for which you are creating an alias. If the host Integration Server is fronted by a proxy, specify the host name or IP address of the proxy server.
Port	An active HTTP or HTTPS listener port defined on the Integration Server specified in the Host Name or IP Address field. If the host Integration Server is fronted by a proxy, specify the port for the proxy server.

6. Under WS Security Properties, if the inbound SOAP request must be decrypted and/or the outbound SOAP request must be signed, do the following:

In this field...

Specify...

Keystore Alias

Alias of the keystore containing the private key used to decrypt the inbound SOAP request or sign the outbound SOAP response.

Important:

The provider must have already given the consumer the corresponding public key.

Key Alias

Alias of the private key used to decrypt the request or sign the response. The key must be in the keystore specified in Keystore Alias.

7. Under WS Security Properties, if the signing certificate chain of an inbound signed SOAP message has to be validated, specify the following:

In this field...	Specify...
Truststore Alias	The alias for the truststore that contains the list of CA certificates that Integration Server uses to validate the trust relationship.

8. Under WS Security Properties, set the timestamp properties that Integration Server uses when working with timestamps.

In this field...	Specify...
Timestamp Precision	Whether the timestamp is precise to the second or millisecond. If you set the precision to milliseconds, Integration Server uses the timestamp format yyyy-MM-dd'T'HH:mm:ss:SSS'Z'. If you set the precision to seconds, Integration Server uses the timestamp format yyyy-MM-dd'T'HH:mm:ss'Z'. If you do not select a precision value, Integration Server will use the value specified for the watt.server.ws.security.timestampPrecisionInMilliseconds parameter.
Timestamp Time to Live	The time-to-live value for the outbound message in seconds. Integration Server uses the Timestamp Time to Live value to set the expiry time in the Timestamp element of outbound messages. The time-to-live value must be an integer greater than 0. If you do not specify a Timestamp Time to Live value, Integration Server will use the value specified for the watt.server.ws.security.timestampTimeToLive parameter.
Timestamp Maximum Skew	The maximum number of seconds that the web services client and host clocks can differ and still allow timestamp expiry validation to succeed. Specify a positive integer or zero. Integration Server uses the timestamp maximum skew value only when you implement WS-Security via a WS-Policy. Integration Server validates the inbound SOAP message only when the creation timestamp of the message is less than the sum of the timestamp maximum skew value and the current system clock time. If you do not specify a timestamp maximum skew value, Integration Server will use the value specified for the watt.server.ws.security.timestampMaximumSkew parameter.

For more information about timestamps in the WS-Security header, see Timestamps in the WS-Security Header.

9. Under Kerberos Properties, provide the following Kerberos-related details that will be used for all providers that use this endpoint alias.

Note:

These fields are available only for provider endpoint aliases using the HTTPS transport type.

In this field...	Specify...
JAAS Context	The custom JAAS context used for Kerberos authentication. In the following example, JAAS Context is WS_KERBEROS_INBOUND: WS_KERBEROS_INBOUND { com.sun.security.auth.module.Krb5LoginModule required refreshKrb5Config=true storeKey=true isInitiator=false debug=true; }; The is_jaas.cnf file distributed with Integration Server includes a JAAS context named IS_KERBEROS_INBOUND that can be used with inbound requests.
Principal	The name of the principal to use for Kerberos authentication.
Principal Password	The password for the principal that is used to authenticate the principal to the KDC. Specify the principal password if you do not want to use the keytab file that contains the principals and their passwords for authorization. The passwords may be encrypted using different encryption algorithms. If the JAAS login context contains useKeyTab=false, you must specify the principal password.
Retype Principal Password	The above principal password.
Service Principal Name Format	Select the format in which you want to specify the principal name of the service that is registered with the principal database.
	Select...	To...
	host-based	Represent the principal name using the service name and the hostname, where hostname is the host computer. This is the default.
	username	Represent the principal name as a named user defined in the LDAP or central user directory used for authentication to the KDC.
Service Principal Name	The name of the principal for the service that the Kerberos client wants to access. This can be obtained from the WSDL document published by the provider of the Kerberos service. Specify the Service Principal Name in the following format: principal-name.instance-name@realm-name

10. Under Message Addressing Properties, provide the following addressing information relating to the delivery of the message. The message addressing properties define the addressing information that can be attached to the SOAP message.

In this field...	Specify...
To	URI of the destination of the SOAP message. In the Reference Parameters field, specify additional parameters, if any, that correspond to <wsa:ReferenceParameters> properties of the endpoint reference to which the message is addressed. Optionally, you can specify metadata (such as WSDL or WS-Policy) about the service in the Metadata Elements field. You can also specify Extensible Elements, which are elements other than those specified as part of the Metadata and Reference Parameters. You can specify more than one reference parameter, metadata element, or extensible element. Click the ‘+’ icon to add more rows and the ‘x’ icon to delete the rows.
Response Map	Address to which the provider will send the reply or fault message and the corresponding message addressing alias. Integration Server retrieves the authentication details needed to send the response from the message addressing alias mapped to the address. In the Address field, specify the URI to which the provider will send the reply or the fault message. From the Message Addressing Alias list, select the message addressing endpoint alias from which Integration Server will retrieve the authentication details. Integration Server uses the authentication details to send the response to the ReplyTo or FaultTo endpoints. Click the ‘+’ icon to add more rows and the ‘x’ icon to delete the rows.

11. Under Reliable Messaging Properties, check Enable to provide reliable messaging information specific to the endpoint alias you are creating.

12. Provide the following reliable-messaging information to ensure reliable delivery of the message between a reliable messaging source and destination.

In this field...	Specify...
Retransmission Interval	The time interval (in milliseconds) for which a reliable messaging source waits for an acknowledgement from the reliable messaging destination before retransmitting the SOAP message. The default is 6000 milliseconds.
Acknowledgement Interval	The time interval (in milliseconds) for which the reliable messaging destination waits before sending an acknowledgement for a message sequence. Messages of the same sequence received within the specified acknowledgement interval are acknowledged in one batch. If there are no other messages to be sent to the acknowledgement endpoint within the time specified as the acknowledgement interval, the acknowledgement is sent as a stand-alone message. The default is 3000 milliseconds.
Exponential Backoff	Whether to use the exponential backoff algorithm to adjust the retransmission interval of unacknowledged messages. Adjusting the time interval between retransmission attempts ensures that a reliable messaging destination does not get flooded with a large number of retransmitted messages.
	Select...	To...
	true	Increase the successive retransmission intervals exponentially, based on the specified retransmission interval. For example, if the specified retransmission interval is 2 seconds, and the exponential backoff value is set to true, successive retransmission intervals will be 2, 4, 8, 16, 32, and so on if messages continue to be unacknowledged. This is the default.
	false	Use the same time interval specified in the Retransmission Interval field for all retransmissions.
Maximum Retransmission Count	The number of times the reliable messaging source must retransmit a message if an acknowledgement is not received from the reliable messaging destination. To specify that there is no limit to the number of retransmission attempts, set the value of Maximum Retransmission Count to -1. The default is 10.

13. Click Save Changes.

Contact Support | Community | Feedback