IBM Sterling Ideas

Submit new product ideas for IBM Sterling solutions. Before you submit, please review existing ideas; if an idea close to yours already exists, it's better to add comments or vote on the existing idea. We will review your ideas and use them to help prioritize our product development. Best of all, the portal will automatically update you when the status of your idea has been changed.

IBM is transforming its request for enhancement (RFE) process. The purpose of the transformation is to provide a more consistent experience for you to submit requests and to enable IBM product owners to respond to your requests more quickly. For more information click here.

Connect with IBM experts and your peers on the Supply Chain Collaboration Community and the Order Management Interest Group

Support for token authentication

Some of REST APIs for IBM products have token authentication implemented. I.e., call a sign in API to get a token, and then use the token in a HTTP Header for all other API calls.

Example Products:

IBM Sterling Secure Proxy:

IBM Connect Direct:

PEM currently does not support this form of authentication in API configuration and API dialogs.

  • Avatar32.5fb70cce7410889e661286fd7f1897de Guest
  • Jun 6 2018
  • Uncommitted Candidate
How will this idea be used?

This will be used to call REST APIs of IBM SSP and CD products from PEM.

What is your industry? Non-Industry Specific
What is the idea priority? Medium
  • Attach files
  • Avatar40.8f183f721a2c86cd98fddbbe6dc46ec9
    Guest commented
    17 Sep 09:55am

    A SIGNON to C:D Server from PEM via REST API is succesful if using these headers (the value of X-XSRF is fixed and documented on KC, Authorization is Userid/Password in base 64)

    Content-Type=application/JSON; charset=iso-8859-1
    Authorization=Basic ZG5pY2hlOnN0ZXJsaW5n

    PEM is receiving then only the body as an example:

    [ {
    "messageCode" : 200,
    "message" : "Signon is successful",
    "version" : "",
    "nodeName" : "CDUNIX61"
    } ]

    The header is not captured, but we need these values like:


    Authorization : oTqJSyTijkZFyoG4iONdpLeX6n8SSZtegbJVusJSxlPShEEcsibA...

    fur subsequent REST API Calls to the C:D Server otherwise we get an error.

    This can be verified and tested from Postman or other utilities.


  • Avatar40.8f183f721a2c86cd98fddbbe6dc46ec9
    Guest commented
    14 Jan, 2019 01:54pm

    For full Connect:Direct support tokenization will not be enough. You will need to enable as well numbers in json documents instead of only text. Following an example:

    This is how the C:D signon json should look like:


    In PEM you can do this if port number is hard coded. Anyway if you gathered the port number in the PEM activity at some point in time and now want to reuse the number PEM can only generate the number as text. See following the example:


    Stating the port as text instead of number fails the C:D signon.

    PEMs missing support for number stating in json documents effects not only the C:D signon but as well other C:D APIs where number are needed instead of text.

    Just to make it clear. PEM prevents saving API calls like this:


    You can only save it as follows which is by stating a number as text in the json document:


  • Avatar40.8f183f721a2c86cd98fddbbe6dc46ec9
    Guest commented
    27 Dec, 2018 07:22am

    Please consider as well to provide:

    • an out of the box activity for SSP and C:D use cases for PEM and PP
    • enhance the partner repository¬† and modify the SSP and C:D configurations.