Understanding Securing Integration Environments
This section discusses types of integration security and provides an overview of security terminology used in conjunction with PeopleSoft Integration Broker.
Encryption supports data privacy. When encryption is implemented, the sender translates the content of a transaction into a secret code that only the receiver can decrypt. PeopleSoft Integration Broker supports the Secure Sockets Layer (SSL) protocol and Transport Layer Security (TLS) protocol for data encryption.
Note: The TLS security protocol is the successor to the SSL security protocol. The steps for setting up SSL and TLS are similar, and hence are referenced as “SSL/TLS” in this topic. However, it's important to note that while these protocols are similar, they do not interoperate.
You can employ SSL/TLS encryption at the web server level to secure data sent between your web server and that of your integration partners.
You can implement web server SSL/TLS encryption with integration partners running on all PeopleTools 8.4x systems and third-party systems.
You use digital certificates to implement SSL/TLS encryption.
Web services security (WS-Security) is implemented on the integration gateway for inbound and outbound integrations with third-party systems.
You can implement WS-Security using username tokens or Security Assertion Markup Language (SAML) tokens .
You can implement WS-Security with integration partners running on PeopleTools 8.48 and later systems and third-party systems.
WS-Security using Username Token Profile
The WS-Security Username Token Profile defines a standard way of identifying the requestor by “username”, and optionally using a password (or shared secret, or password equivalent) to authenticate that identity to the web service producer.
On outbound request processing, PeopleSoft Integration Broker generates a WS-Security UsernameToken, which may include a password. The WS-Security information is added to the SOAP request on the integration gateway prior to sending to the integration partner.
On inbound processing, PeopleSoft Integration Broker can process requests received from integration partners that contain WS-Security UsernameToken and password in the SOAP header of the inbound SOAP request.
WS-Security using SAML Token Profile
The SAML Token Profile uses assertions to define a standard way to associate common information such as issuer ID, assertion ID, subject and so on.
On outbound request processing, PeopleSoft Integration Broker adds a WS-Security SOAP header to the service operation that contains SAML credentials defined in the node definition for the node.
On inbound processing, the PeopleSoft system checks for the existence of a WS-Security SOAP header. If it exists, the integration gateway decrypts the SAML token (if it has been encrypted) to restore the user ID information to clear text format.
Outbound requests connect from the application server to the integration gateway using an MIME over HTTP connection. To secure the connection you can employ client authentication. This option is typically implemented when the application server and integration gateway reside on separate machines. Client authentication is used only on outbound transactions, since inbound transactions connect between the integration gateway and application server are made using Jolt connection strings.
Note: If you implement client authentication you must also implement web server SSL encryption.
You can implement client authentication with integration partners running on all PeopleSoft 8.4x systems and third-party systems.
Nonrepudiation is a form a digital security that ensures that a transferred message has been sent and received by the parties claiming to have sent and received the message. It is also a method of guaranteeing that the sender of a message cannot later deny having sent the message and that the recipient cannot deny having received the message.
You can implement nonrepudiation with integration partners running on all PeopleSoft 8.4x systems and third-party systems.
Service operations are secured at the user level. On an outbound transaction, user authentication sets the user ID to assign to the service operation.
When user authentication is implemented a user ID or user ID and password are required.
For inbound transactions, user authentication determines the user ID associated with the inbound service operation. If a user ID and password are required to invoke a service operation, the system validates the user ID to see if it is a member of the permission list to which the service operation is assigned.
You can implement user authentication with integration partners running on PeopleSoft 8.48 and later systems and third-party systems.
Use node-level security for integrations with nodes running on earlier PeopleTools 8.4x releases.
To implement node-level security you define an authentication option for the node using the Nodes page. You can use a node certificate or a password as authentication options.
Node-level security pertains to inbound and outbound processing and authentication is performed on the application server.
You can implement node authentication with integration partners running on all PeopleSoft 8.4x systems and third-party systems.
The user ID that is authenticated during user authentication is validated against the permission list to which the service operation is assigned.