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 (https://ideas.ibm.com).
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 updateson them if they matter to you. If you can't find what you are looking for,
Post your ideas
Post an idea.
Get feedback from the IBM team and other customers to refine your idea.
Follow the idea through the IBM Ideas process.
Specific links you will want to bookmark for future use
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.)
What is your industry?
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.
Do not place IBM confidential, company confidential, or personal information into any field.