Watson Supply Chain Ideas
Submit new product ideas for Watson Supply Chain 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
Submit ideas for other Watson Customer Engagement Products:
• Watson Marketing
• Watson Campaign Automation
• Watson Commerce
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.)
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|
|Link to original RFE|