Cloud Management and AIOps
Hide about this portal
This is an IBM Automation portal for Cloud Management, Technology Cost Management, Network Automation and AIOps products. 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 updates on 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
Welcome to the IBM Ideas Portal (https://www.ibm.com/ideas) - Use this site to find out additional information and details about the IBM Ideas process and statuses.
IBM Unified Ideas Portal (https://ideas.ibm.com) - Use this site to view all of your ideas, create new ideas for any IBM product, or search for ideas across all of IBM.
ideasibm@us.ibm.com - Use this email to suggest enhancements to the Ideas process or request help from IBM for submitting your Ideas.
Hello Máté
"Configuring single sign-on is a delicate topic which requires attention to details and understanding of the components." no worries: we do not ask you to verify it during regular users group mapping. Confusing thing is our documentation says OWNER which supposed to be able to log in always. And not when someone messed up with the mapping. Hence our offer is in the dialog where Instana offers to specify OWNER USER, allow to do OWNER MAPPING at the dialog, which will ensure that the mapping is correct THE SAME WAY AS IT IS DONE FOR OWNER USER. That will allow mess up with mapping and will have no such effect as we have now.
Thank you
Thank you for the feedback. But maybe at least you could remove this misleading text from the UI: "Enter an account to be automatically assigned to the owner group." - which brought up this issue in the very fist place. (see picture "01 ...")
Configuring single sign-on is a delicate topic which requires attention to details and understanding of the components. Especially with group mapping - deny access to users with no mapping, the risk of being locked out is called out both in the product and documentation.
Inherently from how and when user attributes are available for evaluation, which is exclusively at login time, there is no way for the product to know if a mapping is "correct" or not. It is not something we can programatically evaluate instead of the admin, as we don't know what attributes their IdP will include during login with which values.
As the documentation states, we suggest testing the mapping to assure at least the admin configuring mapping will be assigned to a group with access to making further adjustments and not locking everybody out of the product.
Even for setting up SSO, we suggest creating a fallback API token with access to configuring authnetication methods, so that can be used to remove the SSO configuration in case the customer's IdP becomes unavailable and allow for password logins in the meantime.
See the attached screenshots for how the customer locked itself out when trying out the LDAP integration in the first place.