Implementing Web Services Security
This section provides and overview of WS-Security and WS-Security processing in PeopleSoft Integration Broker. It also discusses prerequisites for implementing WS-Security in PeopleSoft Integration Broker and discusses how to:
Implement WS-Security for inbound integration (Username Tokens).
Implement WS-Security for inbound integration (SAML Tokens).
Implement WS-Security for outbound integration (Username and SAML Tokens).
Override node-level WS-Security settings on routing definitions.
Implement WS-Security on services consumed using the Consume Web Services wizard.
This section also describes WS-Security configuration options for outbound integrations and provides examples for WS-Security SOAP message headers.
This section provides an overview of implementing WS-Security in PeopleSoft Integration Broker.
WS-Security Standard Supported
PeopleSoft implements WS-Security in accordance with Oasis standards.
Within this framework, PeopleSoft implements:
Username tokens.
SAML tokens.
The PeopleSoft implementation of WS-Security supports:
Clear-text username token. (Password is optional.)
Digitally signed username token.
Digital signatures apply to the SOAP message header and SOAP message body.
Encrypted username token.
You specify to encrypt the SOAP header only, SOAP header and message body, or the message body only
Encrypted SAML assertion token.
You specify to encrypt the SOAP header only, SOAP header and message body, or the message body only
Please visit the My Oracle Support website for information about the current versions of the WS-Security standards, profiles, and namespaces supported by PeopleTools.
UsernameToken Profile
A UsernameToken is the means of identifying a requestor by user name to authenticate the user's identity to the web service provider. A password may also be used in conjunction with the user name.
The UsernameToken is supplied in the <UsernameToken> element in the WS-Security SOAP header that gets added to an inbound or outbound service operation when WS-Security is implemented. The elements included in the credential are discussed in the following section.
On outbound service operations, the values that the PeopleSoft system populates in the UsernameToken profile can be derived from an external user ID that you specify on the node definition for the external node. It can also be derived from the default user ID specified on the external node definition. In addition, you can choose to digitally sign and encrypt this information.
SAML Token Profile
The Security Assertion Markup Language (SAML) is an XML-based framework for exchanging security information. All SAML tokens include the following common information as defined by Oasis standards:
Issuer ID.
Subject.
Name.
Subject confirmation.
Conditions under which the assertion is valid.
Example of these conditions are NotBefore and NotOnOrAfter.
This security information is expressed in the form of assertions about subjects, where a subject is an entity that has an identity in some security domain.
The following pseudocode shows an example of a SAML token:
<Assertion AssertionID="d9aeaa4c1126df5ee0c6df64fdf961b1" IssueInstant="2008-05-
14T18:18:47.246Z" Issuer=".peoplesoft.com" MajorVersion="1" MinorVersion="1"
xmlns="urn:oasis:names:tc:SAML:1.0:assertion" xmlns:saml="urn:oasis:names:tc:
SAML:1.0:assertion" xmlns:samlp="urn:oasis:names:tc:SAML:1.0:protocol">
<Conditions NotBefore="2008-05-14T18:18:47.184Z" NotOnOrAfter="2008-05-14T18:
28:47.184Z"/>
<AuthenticationStatement AuthenticationInstant="2008-05-14T18:18:47.215Z" AuthenticationMethod="urn:oasis:names:tc:SAML:1.0:am:password">
<Subject>
<NameIdentifier NameQualifier=".peoplesoft.com">QEDMO</NameIdentifier>
<SubjectConfirmation>
<ConfirmationMethod>urn:oasis:names:tc:SAML:1.0:cm:sender-vouches
</ConfirmationMethod>
</SubjectConfirmation>
</Subject>
</AuthenticationStatement>
</Assertion>
Note these points about PeopleSoft SAML assertions:
The PeopleSoft SAML token is concerned with the authentication statement only.
The PeopleSoft SAML token supports SAML with digital signature and encryption. SAML tokens without digital signatures are not supported.
The PeopleSoft SAML profile of WSS: SOAP Message Security requires that systems support sender-voucher methods of subject confirmation.
The SAML Assertion validity or condition by default is set to 10 minutes. However, you can override the default time by adding org.apache.ws.security.saml.AssertValidMins=15 in the wssSAML.properties file which is located in the \\WEB-INF\classes\wssSAML.properties directory.
WS-Security SOAP Header
Inbound and outbound transactions that are secured with WS-Security pass the security credentials in a WS-Security SOAP header that is added to the service operation.
The following elements can appear in the WS-Security SOAP header generated by the integration gateway:
Element |
Description |
---|---|
<wsse:UsernameToken> |
Username and optional password to authenticate. |
<wsse:Username> |
Username to use for authentication. On outbound integrations this name can be generated using the External User ID or Default User ID values that you define on the node definition. In addition, you can select to digitally sign and encrypt this value. |
<wsse:Password> |
(Optional.) Password for the authentication username. On outbound integrations this password matches that specified for the External User Id or Default User ID used to generate the username. If you select to digitally sign or encrypt the username, this password is digitally signed or encrypted as well. |
<saml:Assertion> |
SAML assertion token to use for authentication. You can encrypt this value. |
The following example shows a WS-Security SOAP header for an outbound service operation generated by the PeopleSoft system:
<soapenv:Header>
<wsse:Security soapenv:mustUnderstand="1" xmlns:wsse=
"http://docs.oasis-open.org/wss/2004/01/oasis-200401-
wss-wssecurity-secext-1.0.xsd">
<wsse:UsernameToken>
<wsse:Username>PTDMO</wsse:Username>
<wsse:Password Type="http://docs.oasis-open.org/
wss/2004/01/oasis-200401-wss-username-token-profile-
1.0#PasswordText">PTDMO</wsse:Password>
</wsse:UsernameToken>
</wsse:Security>
</soapenv:Header>
SAML assertions and references to assertion identifiers are contained in the <wsse:Security> element, which in turn is included in the <SOAP-ENV:Header> element. The following example shows SAML assertions conveyed within a WS-Security header as part of a SOAP message:
<SOAP-ENV:Envelope>
<SOAP-ENV:Header>
<wsse:Security>
<saml:Assertion> - - - </saml:Assertion>
</wsse:Security>
</SOAP-ENV:Header>
<SOAP-ENV:Body> - - - </SOAP-ENV:Body>
</SOAP-ENV:Envelope>
This section provides overviews of:
Inbound WS-Security processing using Username tokens.
Outbound WS-Security processing using Username tokens.
Inbound WS-Security Processing using Username Tokens
The inbound processing of service operations that are WS-Security-compliant using Username tokens occurs on the integration gateway.
Image: Inbound WS-Security Processing using Username Tokens
This diagram illustrates inbound WS-Security processing in PeopleSoft Integration Broker when it is implemented. The diagram shows all possible security processing for an inbound integration to show where in the processing flow WS-Security processing occurs. WS-Security processing is highlighted in the foreground of the diagram.
The diagram illustrates the steps in WS-Security processing, including validation that the service operation contains a WS-Security SOAP header with a username token, validation of a digital signature if implemented, decryption of the username token if encrypted, and passing the external user ID and password to the application server.
![Inbound WS-Security Processing using Username Tokens](img/ia2cf27cn-799b.png)
When any transaction arrives at the integration gateway, the PeopleSoft system checks for the existence of a WS-Security SOAP header. If it exists, the integration gateway validates the digital signature if it exists, and decrypts the UsernameToken and optional password to restore the user ID information to clear text format.
The integration gateway then passes the user ID information, and UsernameToken password if provided by the sender, to the application server, where additional security processing is performed.
Outbound WS-Security Processing using Username Tokens
This section discusses outbound WS-Security processing using username tokens by PeopleSoft Integration Broker on outbound integrations.
WS-Security processing occurs on the integration gateway.
Image: Outbound WS-Security Processing using Username Tokens
This diagram illustrates outbound WS-Security processing using username tokens when it is implemented. The diagram shows all possible security processing for an outbound integration to show where in the processing flow WS-Security processing occurs. WS-Security processing is highlighted in the foreground of the diagram.
The diagram illustrates the steps of WS-Security processing using username tokens, including validating the external user ID/password or default user ID from the node definition, the setting of the username token type, the encryption of the token if specified, and the digital signing of the token if specified.
![Outbound WS-Security Processing using Username Tokens](img/ia2cf27cn-79fc.png)
When WS-Security is implemented for an outbound service operation, the integration gateway adds a WS-Security SOAP header to the service operation that contains UsernameToken credentials defined in the node definition for the node. The UsernameToken credentials can be comprised of any of the following from the node definition: External User ID, External Password, or Default User ID. Additionally, you can choose to encrypt and digitally sign the UsernameToken credentials.
See Implementing WS-Security for Outbound Integrations (Username and SAML Tokens), Describing WS-Security Configuration Options for Outbound Integrations (Username Tokens).
This section provides overviews of:
Inbound WS-Security processing using SAML tokens.
Outbound WS-Security processing using SAML tokens.
Inbound WS-Security Processing Using SAML Tokens
The inbound processing of service operations that are WS-Security-compliant using SAML tokens occurs on the integration gateway.
Image: Inbound WS-Security Processing using SAML Tokens
This diagram illustrates inbound WS-Security processing using SAML tokens when it is implemented. The diagram shows all possible security processing for an inbound integration to show where in the processing flow WS-Security processing occurs. WS-Security processing is highlighted in the foreground of the diagram.
The diagram illustrates the steps of WS-Security processing using SAML tokens, including validating the existence of a WS-Security SOAP header and SAML token, the decryption of the SAML token if encrypted, and the validation of the passed in user ID.
![Inbound WS-Security Processing using SAML Tokens](img/ia2cf27cn-7997.png)
When any transaction arrives at the integration gateway, 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.
The integration gateway then passes the user ID information to the application server, where additional security processing is performed.
Outbound WS-Security Processing Using SAML Tokens
This section discusses outbound WS-Security processing using SAML tokens.
WS-Security processing occurs on the integration gateway.
Image: Outbound WS-Security Processing Using SAML Tokens
This diagram illustrates outbound WS-Security processing using SAML tokens. The diagram shows all possible security processing for an outbound integration to show where in the processing flow WS-Security processing occurs. WS-Security processing is highlighted in the foreground of the diagram.
The diagram illustrates the steps of WS-Security processing using SAML tokens, including validating the logon user ID, the setting of the SAML token type, and finally the encryption of the token if encryption is specified.
![Outbound WS-Security processing using SAML tokens.](img/i-72fe8c86n-7b85.png)
When WS-Security is implemented for an outbound service operation, the integration gateway adds a WS-Security SOAP header to the service operation that contains SAML credentials defined in the node definition for the node. The SAML credentials can be comprised of any of the following from the node definition: Default User ID or PeopleSoft/Single Signon User ID. Additionally, you can choose to encrypt SAML credentials.
Warning! An any-to-local routing must be used on the sending system for outbound integrations using WS-Security processing and SAML tokens. Integrations will fail using any other routing type.
To implement WS-Security in PeopleSoft Integration Broker you must install digital certificates.
It is also helpful to set the integration gateway logging to 5 as doing so enables you to see the WS-Security tags in the logs.
See Installing Integration Gateway-Based Digital CertificatesManaging Integration Gateway Message and Error Logging.
There is no set up required for implementing WS-Security on inbound integrations. The integration gateway handles all inbound processing.
This section discusses how to:
Set up the PeopleSoft system for handling SAML tokens.
Set up and configure digital certificates.
Setting Up the PeopleSoft System for Handling SAML Tokens
There is some overlap of the steps to set up the PeopleSoft system to handle SAML tokens for integrations using PeopleSoft Integration with those for integrations using WSRP.
The following list describes the steps to set up the PeopleSoft system to handle SAML tokens. Some of the documentation that describes how to perform these steps is located elsewhere in the product documentation, as many of the same set-up steps are required to use SAML tokens with WSRP.
See Configuring WS-Security for PeopleSoft as a WSRP Producer
Create the SAML administrator user ID.
Set up application server and integration gateway digital certificates.
See Installing Application Server-Based Digital Certificates and Installing Integration Gateway-Based Digital Certificates.
Set SAML assertion data.
This section discusses how to:
Specify an authentication token.
Specify a default user ID.
Specify an external user ID and password.
Specifying Authentication Tokens
Use the WS-Security page in the Nodes component (IB_NODE) to set up WS-Security for outbound integrations.
To access the WS-Security page select WS Security tab.
and click theImage: Nodes – WS-Security page
This example illustrates the Nodes – WS-Security page.
![Nodes - WS Security page](img/ia2cf27cn-7996.png)
The previous example shows the WS Security page that appears by default. The options that appear on this page vary, depending on the authentication token type with which you are working.
To set up WS-Security for outbound integrations:
Select
.The Nodes search page appears.
Select the external remote node with which you are integrating.
The Node Definitions page appears.
Click the WS-Security tab.
The WS-Security page appears.
From the Authentication Token Type drop-down list box select an authentication type. The options are:
SAML Token.
Username Token.
To include additional security options, choose any of the following:
Additional information about the possible configuration combinations using these options is discussed elsewhere in this section.
See Describing WS-Security Configuration Options for Outbound Integrations (Username Tokens).
Field or Control
Definition
Encrypt (Optional.) When you check this box, an Encryption Level drop-down list box appears which allows you to choose the level of encryption.
Digitally Signed This option appears only when you select Username Token.
(Optional.) Check the box to digitally sign the token information, including the username and password.
Use Default User ID This option appears only when you select SAML Token.
(Optional.) Check the box to use the Default User ID specified on the Node Definitions page.
If this option is not selected the user ID used is the PeopleSoft single signon user ID.
Use External User ID This option appears only when you select Username Token.
(Optional.) Check the box to use an external user ID for the username.
If you select this option, you specify the external user ID and optional password (recommended) on the Node Definitions page.
Note: If you do not select this option, the Default User ID specified on the Node Definition page is used as the username in the UsernameToken credential.
Click the Save button.
Click the Node Definitions tab.
The Node Definitions page appears.
If you chose to use an external user ID, a dialog box appears indicating that you need to specify the external user ID and optional password. Information on performing that task is described in the Specifying External User IDs and Passwords section.
Encrypting Outbound Messages
When you choose to encrypt messages in an outbound service operation, you have the option to encrypt the entire message, the message body only, or the message header only.
Use the Nodes – WS Security page (IB_NODESECURITY) to work with any of these options.
To access the WS-Security page select WS Security tab.
and click theImage: Nodes – WS Security page
This example illustrates the Nodes – WS Security page. Use this page to choose a message encryption level.
![Nodes - WS Security page](img/ia2cf27cn-7981.png)
When working with an external node type and you select the Encrypt box, the Nodes — WS Security page displays an Encrypt Level drop-down list box from which you can choose an encryption level.
The encryption level options are:
All. This option encrypts the entire message including the message header and body.
Body. Encrypts the message body only.
Header. (Default) Encrypts the message header only.
Specifying Default User IDs
When using the SAML token type to implement WS-Security, you have the option to use the default user ID for processing. You set the default user ID on the external remote node definition using the Node Definitions page.
When you create a node definition, you must supply a value for the Default User ID. However, you a free to change the value at any time.
See Configuring Nodes.
If you do not check the Default User ID option, the system uses the PeopleSoft User ID/Single Signon User ID for the transaction.
Specifying External User IDs and Passwords
When using the Username token type to implement WS-Security, you have the option to specify an external user ID. You define the external user ID on the Nodes – Node Definitions page.
To access the Nodes – Node Definitions page
Image: Nodes – Node Definitions page
This example illustrates the Nodes – Node Definitions page.
![Nodes - Node Definitions page](img/ia2cf27cn-7983.png)
When specifying an external user ID, specifying an external user ID password is recommended.
Note: The Confirm External Password field appears after you specify the external password and tab out of the field.
To specify the External User ID and Password:
On the Node Definitions page, in the External User ID field, enter an external user ID.
(Optional.) In the External Password field, enter the password for the external user ID.
Tab out of the field. A Confirm External Password field appears.
In the Confirm External Password field, re-enter the external user ID password.
Click the Save button.
This section discusses development considerations for implementing WS-Security in asynchronous request/response service operations and discusses how to:
Digitally sign responses in asynchronous request/response service operations.
Secure responses in asynchronous request/response service operations.
Digitally Signing Responses in Asynchronous Request/Response Service Operations
This section applies to inbound asynchronous request/response service operations defined with any-to-local routing definitions.
In any-to-local routing definitions, no requesting node is present. As a result no digital certificate information that is normally defined at the node level is included with the request. However, the request does contain a RequestAliasName parameter that is populated with the certificate issuer’s credentials that the integration gateway uses to process the request.
To digitally sign a response for an asynchronous request/response service operation, in the response set the RequestAliasName parameter equal to the same value that was set for the parameter on the request message. The integration gateway reads that value and can then determine the certificate to use in the response.
The following example shows how to code a digitally-signed response for an asynchronous request/response service operation:
import PS_PT:Integration:INotificationHandler;
class FLIGHTDATA_RETURN implements PS_PT:Integration:INotificationHandler
method FLIGHTDATA_RETURN();
method OnNotify(&MSG As Message);
end-class;
/* constructor */
method FLIGHTDATA_RETURN
end-method;
method OnNotify
/+ &MSG as Message +/
/+ Extends/implements PS_PT:Integration:INotificationHandler.OnNotify +/
/* Variable Declaration */
Local string &str, &value;
Local Rowset &rs;
Local integer #
Local Message &MSG_resp;
Local Record &FLIGHTDATA, &REC;
&rs = &MSG.GetPartRowset(1);
/* process request data */
&MSG_resp = CreateMessage(Operation.FLIGHTPLAN_ARR, %IntBroker_Response);
&rs = &MSG_resp.GetPartRowset(1);
/* popualate response data */
If &MSG.IsSourceNodeExternal Then
/* set WS Addressing information and WS_RequestAliasName
if security to be added to response message */
&MSG_resp.IBInfo.WSA_MessageID = &MSG.IBInfo.WSA_MessageID;
&MSG_resp.IBInfo.WSA_ReplyTo = &MSG.IBInfo.WSA_ReplyTo;
&MSG_resp.IBInfo.WS_RequestAliasName = &MSG.IBInfo.WS_RequestAliasName;
Else
/* request from PSFT system */
&MSG_resp.IBInfo.WSA_ReplyTo = &MSG.TransactionId;
End-If;
%IntBroker.Publish(&MSG_resp);
end-method;
Securing Responses in Asynchronous Request/Response Service Operations
PeopleSoft Integration Broker sends responses for asynchronous request/response service operations to the URL set in the Target Location field in on the Service Configuration page. The URL specified on this page is typically not secure, as it is the URL used for all WSDL, schemas, and web transactions.
When providing asynchronous request/responses, you can dynamically override the URL using the IBInfo object property WSA_ReplyTo. For example:
&MSG.IBINFO.WSA_ReplyTo
You set this property typically before the publish or during the OnSend event.
This section discusses how to:
Override WS-Security settings on routing definitions (General).
Override WS-Security settings on routing definitions (Synchronous Responses).
Override WS-Security settings on routing definitions (Asynchronous Requests/Responses).
Understanding Overriding Node-Level WS-Security Settings on Routing Definitions
You can override node-level WS-Security settings on individual routing definitions for outbound request and response messages. The security settings that you can override are the same as those that appear on the Nodes-WS Security page.
When overriding WS-Security settings for synchronous request messages and asynchronous request/response messages, there are PeopleCode considerations of which you should be aware. In addition, the outbound security overrides on the routing definition for these transaction types work in concert with inbound security validation set on the service operation. These considerations and options are discussed in this section.
Overriding WS-Security Settings on Routing Definitions (General)
When you are working with an outbound routing definition to a external node, the Routing Definitions – Parameters page (IB_ROUTINGDEFNDOC) features a WS-Security link that provides access to options to override node-level WS-Security settings.
To access the Routing Definitions – Parameters page select Parameters tab.
and click theImage: Routing Definitions – Parameters page
This example illustrates the Routing Definitions – Parameters page.
Use the WS Security link under the External Alias field to override node-level WS-Security settings.
![Routings - Parameters page](img/ia2cf27cn-79a5.png)
When you click the WS Security link the Routing Security page (IB_ROUTINGDEFN_SEC) appears.
Image: Routing Security page
This example illustrates the Routing Security page. The Routing Security does not display any override options until you check the Security Override box.
![Routing Security page](img/ia2cf27cn-7988.png)
When you check the Security Override box on the Routing Security page, the WS-Security options that you can override appear on the page.
Image: Routing Security page
Check the Security Override button to view override options. This example illustrates override options when Username Token is the authentication type.
![Routing Security page](img/ia2cf27cn-798f.png)
The WS-Security options that appear and that you can use to set and override in a routing definition, depend on the authentication type and encryption option, if any, set.
To override WS-Security options on a routing definition:
Select
, and select or add a routing definition.Click the Parameters tab.
A WS Security link appears for the outbound request or response message, depending on whether the external node is the sending or receiving node.
Click the WS Security link.
The Routing Security page appears.
Select the Security Override box.
The Authentication Token Type drop-down list box appears.
From the Authentication Token Type drop-down list box, choose an authentication token type with which to work. The options are:
None. (Default.)
SAML Token.
Username Token.
If you choose SAML token or Username token, additional security options appear with which to work. SAML token and Username token security options for outbound messages are discussed elsewhere in this topic.
See Implementing WS-Security for Outbound Integrations (Username and SAML Tokens).
Overriding WS-Security Options on Routing Definitions (Synchronous Responses)
To override the security for a synchronous response, on the Routing Definitions – Parmeters page, select the WS Security link on the Outbound Response Parameter:
If the Encrypted check box is selected then the response message sent from the consumer must be digitally signed if the routing is an any-to-local type routing.
In addition, you can reject a request message that is not digitally signed. To do so, on the Service Operations-General page, from the Security Verification \ drop-down list select Digitally Signed.
Overriding WS-Security Options on Routing Definitions (Asynchronous Request/ Response)
You can use the Routing Security page to encrypt and/or digitally sign outbound responses in asynchronous request/response transactions.
If you select the Encrypted box for the outbound response message, then the message sent from the consumer must be digitally signed if the routing is an any-to-local type routing.
You can then select the Digitally Signed option for Security Verification on the service operation to reject a non-signed request message.
To successfully use WS-Security on a response, within the PeopleCode the RequestAliasName must also be populated on the response Message object from the request Message object. Here is an example in PeopleCode:
&MSG_resp = CreateMessage(Operation.FLIGHTPLAN_DOC_ARR, %IntBroker_Response);
&MSG_resp.IBInfo.WSA_MessageID = &MSG.IBInfo.WSA_MessageID;
&MSG_resp.IBInfo.WSA_ReplyTo = &MSG.IBInfo.WSA_ReplyTo;
&MSG_resp.IBInfo.WS_RequestAliasName = &MSG.IBInfo.WS_RequestAliasName;
The system validates proper encryption based on the request verification selected on the service operation. Select the desired security validation. If the security on the actual request message does not match the value specified in the Security Verification field, an error is sent back to the client.
You can implement WS-Security on service operations you consume using the Consume Web Service wizard.
When using the Consume Services wizard, there is an option to use the default pre-defined WSDL_NODE node or use another existing node as the receiving node for the consumed service operations. The action to take to implement WS-Security on consumed services depends on which of these nodes you are using.
Using the Default WSDL Node
If you choose the default WSDL_NODE node as the receiving node, then you should add/override the node-level WS-Security settings by using the Routing Security page on the routing definition for the created service operation.
If you are using the WSDL_NODE node as the receiving node and the message is to be encrypted, the WS_RequestAliasName must be populated on the request message with the alias name used when adding the provider certificate to the gateway keystore. In addition, in PeopleCode after the message is created add this alias as follows:
&MSG.IBinfo.WS_RequestAliasName = "the alias name from the gateway keystore";
Using an Existing Node
If you use a node other than the WSDL_NODE as the receiving node then you can specify the security settings at the node level on the Nodes- WS Security page or on the Routing Security page on the routing definition.
This section discusses:
Recommended WS-Security configurations for outbound integrations.
Supported WS-Security configurations for outbound integrations.
Non-secure WS-Security configurations for outbound integrations.
Recommended WS-Security Configurations for Outbound Integrations (Username Token)
The following table highlights recommended WS-Security configurations on the PeopleSoft system for outbound integrations using Username tokens. Note that the configuration is always performed on the remote node and that the node type is always External.
External User ID and Password |
Authentication Type |
With SSL Encryption |
Results |
---|---|---|---|
Both |
Username Token with the External User ID option. |
Yes |
The system uses the external user ID and password to generate the username token. The token is generated in clear text. |
Both |
Username Token with the following other options:
|
No |
The system uses the external user ID and password to generate the username token. The token is encrypted and digitally signed. |
Both |
Username Token with the Digitally signed option. |
Yes |
The system uses the external user ID and password to generate the username token. The token is digitally signed. |
External User ID only. |
Username Token with the External User ID option. |
Yes |
The system uses the external user ID to generate the username token. The token is generated in clear text. |
External User ID only. |
Username Token with the following other options:
|
No |
The system uses the external user ID to generate the username token. The token is encrypted and digitally signed. |
External User ID only. |
Username Token with the following other options:
|
No |
The system uses the external user ID to generate the username token. The token is digitally signed. |
Supported WS-Security Configurations for Outbound Integrations (Username Token)
The following table highlights supported WS-Security configurations on the PeopleSoft system for outbound integrations using Username tokens. Note that the configuration is always performed on the remote node and that the node type is always External.
External User ID and Password |
Authentication Type |
With SSL Encryption |
Results |
---|---|---|---|
None. |
Username Token option only. |
Yes. |
The system uses the default user ID defined on the node definition to generate the username token. The token is generated in clear text. |
None. |
Username Token with the following other options:
|
No. |
The system uses the default user ID defined on the node definition to generate the username token. The token is encrypted and digitally signed. |
None |
Username Token with the Digitally Signed option. |
No. |
The system uses the default user ID defined on the node definition to generate the username token. The token is digitally signed. |
Non-Secure WS-Security Configurations for Outbound Integrations (Username Token)
The following table highlights non-secure WS-Security configurations on the PeopleSoft system for outbound integrations using Username tokens. Note that the configuration is always performed on the remote node and that the node type is always External.
Warning! The following configurations are not secure! This information is provided to advise you about configurations that can lead to breaches in security. Use the recommended or supported configurations discussed in the previous sections for configuring your system .
External User ID and Password |
Authentication Type |
With SSL Encryption |
Results |
---|---|---|---|
Both |
Username Token with the External user ID option. |
No. |
The system uses the external user ID and password to generate the username token. The token is generated in clear text. |
None. |
Username Token option only. |
No. |
The system uses the default user ID defined on the node definition to generate the username token. The token is generated in clear text. |
Both |
Username Token with the following options:
|
No. |
The system uses the external user ID and password to generate the username token. The token is encrypted. |
None. |
Username Token with the following options:
|
No. |
The system uses the default user ID and password to generate the username token. The token generated is encrypted. |
This section provides the following WS-Security code examples:
WS-Security UsernameToken in ciphertext and digitally signed.
WS-Security UsernameToken with clear text user name and password.
WS-Security UsernameToken with clear text with user name only.
Example 1: WS-Security UsernameToken in Ciphertext and Digitally Signed
The following code example shows a WS-Security SOAP header that contains a UsernameToken in cipher text and that is digitally signed. This is the most secure configuration for WS-Security in PeopleSoft Integration Broker.
<soapenv:Header>
<wsse:Security soapenv:mustUnderstand="1" xmlns:wsse="http://docs.
oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0
.xsd">
<xenc:EncryptedKey>
<xenc:EncryptionMethod Algorithm="http://www.w3.org/2001/04/
xmlenc#rsa-1_5"/>
<ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
<wsse:SecurityTokenReference>
<ds:X509Data>
<ds:X509IssuerSerial>
<ds:X509IssuerName>CN=PeopleTools TEST root CA,
DC=peoplesoft,DC=com,OU=PeopleTools Development,
O=PeopleSoft Inc,L=Pleasanton,ST=CA,C=US</ds:
X509IssuerName>
<ds:X509SerialNumber>174697022083003580418117</ds:
X509SerialNumber>
</ds:X509IssuerSerial>
</ds:X509Data>
</wsse:SecurityTokenReference>
</ds:KeyInfo>
<xenc:CipherData>
<xenc:CipherValue>q8ytyn0kRisc3i7GwGtoQuU6NSXfvSNoJg76PWpppt
4b4DoH8bRObvht8GLu904OExYBrNDB26qqOlKVpIzGrCJFgetlhikGghH/u2
9GC96+YfFdxSFqcJo5PpJR1KnVZP0sKO4IHVIEcuxp7MonoV6dm5kd0d8atVw
KXhJe5Yk=</xenc:CipherValue>
</xenc:CipherData>
<xenc:ReferenceList>
<xenc:DataReference URI="#EncDataId-13925529"/>
</xenc:ReferenceList>
</xenc:EncryptedKey>
<ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
<ds:SignedInfo>
<ds:CanonicalizationMethod Algorithm="http://www.w3.org/
2001/10/xml-exc-c14n#"/>
<ds:SignatureMethod Algorithm="http://www.w3.org/2001/04/
xmldsig-more#rsa-sha256"/>
<ds:Reference URI="#id-763474">
<ds:Transforms>
<ds:Transform Algorithm="http://www.w3.org/2001/10/
xml-exc-c14n#"/>
</ds:Transforms>
<ds:DigestMethod Algorithm="http://www.w3.org/2001/04/
xmlenc#sha256"/>
<ds:DigestValue>cNBCuvnSP5MMlsJvaHMrZm9CsK0=</ds:
DigestValue>
</ds:Reference>
<ds:Reference URI="#id-13925529">
<ds:Transforms>
<ds:Transform Algorithm="http://www.w3.org/2001/10/
xml-exc-c14n#"/>
</ds:Transforms>
<ds:DigestMethod Algorithm="http://www.w3.org/2001/04/
xmlenc#sha256"/>
<ds:DigestValue>p+IodojBA2QzX6p9xe6PKJyUKSg=</ds:
DigestValue>
</ds:Reference>
</ds:SignedInfo>
<ds:SignatureValue>D/kTMJZvxnv7fjWzmvKC1xe8VSDiSz4lZDzFrf8q
FFoXux+C2xD47TLWnD7m8ejp/Un3mzjWkVN8S4FpwRr/ymrxWTKWLrjCO
zmjSW+ZbjGvs5UfpFyzEH7PWrXt+LnTeMKKJWYjzOi7HCHCVK9aC/RZCt
7PkCbSZ7DJoOQO/lU=
</ds:SignatureValue>
<ds:KeyInfo Id="KeyId-28705465">
<wsse:SecurityTokenReference wsu:Id="STRId-7131385" xmlns:wsu=
"http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-
wssecurity-utility-1.0.xsd">
<ds:X509Data>
<ds:X509IssuerSerial>
<ds:X509IssuerName>CN=PeopleTools TEST root CA,DC=
peoplesoft,DC=com,OU=PeopleTools Development,
O=PeopleSoft Inc,L=Pleasanton,ST=CA,C=US
</ds:X509IssuerName>
<ds:X509SerialNumber>174332155640842765207620
</ds:X509SerialNumber>
</ds:X509IssuerSerial>
</ds:X509Data>
</wsse:SecurityTokenReference>
</ds:KeyInfo>
</ds:Signature>
<xenc:EncryptedData Id="EncDataId-13925529" Type="http://www.w3.
org/2001/04/xmlenc#Element">
<xenc:EncryptionMethod Algorithm="http://www.w3.org/2001/04/
xmlenc#tripledes-cbc"/>
<xenc:CipherData>
<xenc:CipherValue>wqrOr/efBcghEdcTPZMPqbrUu9mF+iCSLf2UhLYjOc
Vg30+58TX3FCKXJhExi3iEdbuVrYt60mq3Maka6cg6+0JXw0Qmbjbl5qG8p
sHajRtenvZc3dJeLRDclplbqUw65cDvBqQz+3+K5DBMh+tIlutf+0j3D9MiO
3ht4Ni4bJ9Zk/h+DY9y05px2xtOMsXSrEhn4STGz4SdaOwFYHDUTT+y+D6zj
GYxpRAexVQxAkjehW1JEGhyaqqdDmIYPJxCSy8JBc7xL/CaUng98ak8hAr38I
obBt1qjlYjGo9VybfrX5j9lqn6pcrWX6x3o/9JYXeiaY36qHj+jVm0STq1fPr
DDfh6ZI0/aeks83MnesMrX9bB7aKOo67DPjJstRvW/qfbIo3wYgv+3Jl68sHv
u6p6GZEujaLIYIosJ+HtDzmZ2Q9aOtkk7+zFwDohkljAwmNSe3bt9e2i60pgF
fVYcxg1Pwfz03MyKm83m5cLT9INb8LHK/GsKOl+9GvQ49nsJ6EYuAcPO4Q8Sr
BvLVVPY3Qljw+4ZOZOEcndxVw+vU9n7cAMyeYa7p5Jpl6l2naeC4J98MIa16D
CuVdvLIkipurkn2lbVYe5/m0SYbVibvTWE3BIQlWzF/mRHKkOhBhTaKg/Y/Q7
sRlKcxKHtjnsjX2d4hTqTRYOoKFEH5sVi+gtyhgogiXRjg8wCAS68cYVwAFre
W9xf2/ojGJFcO354Sk5rWt3GZzK8yRG5Jcgf5pgxnKC3LVgvvGPQM2Q/yGy1N
OrXDhtzc80zM2SIOjv3A90Gzj9RGKzrWm+bw4QlhveY+rwyZGZRu3ibVUm+mi
Ul7CdBBbrLOfz9xY45w3H2c6mtu98OwhuoiYHeVS/FkdpL+ztLmZi7gINIAQi
sCZudpyKsZIcEhTPbTjQcdCVPZim1v9HFft00cSOE1u1CVEYNOSuCisrLJIch
zAtE7gfa86/NcyEGmUBtvRsGVPkPq81cw1AosV8x4+KPCpTjxxeuMKGrowC2h
Y/7DY+IYn4
</xenc:CipherValue>
</xenc:CipherData>
</xenc:EncryptedData>
</wsse:Security>
</soapenv:Header>
Example 2: WS-Security UsernameToken with Clear Text Username and Password
The following code example shows a WS-Security SOAP header that contains a clear-text UsernameToken credential that contains a user name and a password.
<soapenv:Header>
<wsse:Security soapenv:mustUnderstand="1" xmlns:wsse="http://docs.oasis-
open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd">
<wsse:UsernameToken>
<wsse:Username>IBUSER</wsse:Username>
<wsse:Password Type="http://docs.oasis-open.org/wss/2004/01/
oasis-200401-wss-username-token-profile-1.0#PasswordText">IBUSER1
</wsse:Password>
</wsse:UsernameToken>
</wsse:Security>
</soapenv:Header>
Example 3: WS-Security UsernameToken with Clear Text User Name Only
The following code example shows a WS-Security SOAP header that contains a clear-text UsernameToken credential that contains only a user name. No password is specified.
<soapenv:Header>
<wsse:Security soapenv:mustUnderstand="1" xmlns:wsse="http://docs.
oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd">
<wsse:UsernameToken>
<wsse:Username>QEMGR</wsse:Username>
<wsse:Password/>
</wsse:UsernameToken>
</wsse:Security>
</soapenv:Header>