Skip to Main Content
IBM Sterling

This portal is to open public enhancement requests for IBM Sterling products and services. To view all of your ideas submitted to IBM, create and manage groups of Ideas, or create an idea explicitly set to be either visible by all (public) or visible only to you and IBM (private), use the IBM Unified Ideas Portal (

Shape the future of IBM!

We invite you to shape the future of IBM, including product roadmaps, by submitting ideas that matter to you the most. Here's how it works:

Search existing ideas

Start by searching and reviewing ideas and requests to enhance a product or service. Take a look at ideas others have posted, and add a comment, vote, or subscribe to updates on them if they matter to you. If you can't find what you are looking for,

Post your ideas
  1. Post an idea.

  2. Get feedback from the IBM team and other customers to refine your idea.

  3. Follow the idea through the IBM Ideas process.

Specific links you will want to bookmark for future use

Welcome to the IBM Ideas Portal ( - Use this site to find out additional information and details about the IBM Ideas process and statuses.

IBM Unified Ideas Portal ( - Use this site to view all of your ideas, create new ideas for any IBM product, or search for ideas across all of IBM. - Use this email to suggest enhancements to the Ideas process or request help from IBM for submitting your Ideas.

Status Planned for future release
Categories Security
Created by Guest
Created on Jun 6, 2018

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.

What is your industry? Non-Industry Specific
How will this idea be used?

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

  • Guest
    Sep 17, 2020

    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.


  • Guest
    Jan 14, 2019

    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:


  • Guest
    Dec 27, 2018

    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.