IBM Sterling Ideas

formerly Watson Supply Chain

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. Order Management, Store Engagement, Watson Order Optimizer, Inventory Visibility, CPQ and Call Center are now part of Watson Supply Chain

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

Allow ICC to authenticate users via group membership (eg. using SEAS)

Typical enterprises do not define individual user accounts and groups to every application, as is currently required for ICC.Instead, user accounts and groups within an LDAP directory (such as Active Directory) are used and the applications recognise this. This is the minimum expectation from a modern product. It's not realistic for each product used to maintain it's own list of accounts and roles.

Although user account validation can be performed using ICC and Sterling External Authentication Services, it's very inflexible. ICC only recognises a single SEAS profile so everyone would be authenticated using the same settings (eg. user/password correct, user is a member of group 'x'). The group used has no bearing on the ICC role used so if the user changes role, they need to be moved to a different role in ICC - which needs someone with suitable privileges in ICC.

If ICC were to associate roles with different SEAS profiles (eg. a user role, an admin role, etc), then SEAS can implement different criteria (eg. membership of a group) for each function.

Going further, if ICC roles are associated with SEAS profiles, individual user accounts do not even need to exist within ICC. If SEAS authenticates a user against that role, that user account must therefore exist and needn't have been defined to ICC previously.


For comparison, C:D Windows functional group authorities provide similar functionality. For instance, a user can logon as 'user@domain', then they are checked in order as to what functional group authorities apply (first matching group is used). This removes all of the user/role management from C:D Windows and places it into Active Directory.

Similar functionality should be implemented within ICC either using multiple SEAS profiles within ICC or similar mechanism (I noticed a request for LDAP authentication without SEAS for instance).


SEAS itself has the required functionality already; ICC knows how to use a SEAS profile and knows about different roles so this needn't be a large amount of work - it's mostly allowing different SEAS profiles to be used for each role rather than it being a global setting. Removing user accounts is a further step but ties in with the overall aim of removing all user/group administration from ICC and leaving it to LDAP/AD.


(Note, this was also logged within case TS001692038 which may have further information.)

  • Avatar32.5fb70cce7410889e661286fd7f1897de Guest
  • Mar 14 2019
  • Under Consideration
How will this idea be used?

This will allow enterprises to implement centralised security without having to duplicate user accounts, groups and administration of them within ICC.

What is your industry? Banking
What is the idea priority? High
  • Attach files
  • Avatar40.8f183f721a2c86cd98fddbbe6dc46ec9
    Guest commented
    1 Aug, 2019 03:41am

    ICC is rated internally as "Non-Compliant "due to not using an AD group . This is serious issue and we will be manually auditied until this is available . Managers are not prearpared to use the product due this . This is causing us not to get value from tool. We are considering decommission the tool unless we can get a ETA on AD integration .