Integration
Hide about this portal
This is an IBM Automation portal for Integration 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.
Hi Ben, thanks for reaching out - apologies, I lost track of the 2nd Dec notification...
Exactly as you depict in your previous update "letting flow developers have access to information in the security profile"
Without extending the use of the Security Profiles for some further, finite number of, use cases... if the extension option included being able to configure a Security Profile to bring-in credentials / provide access to them at runtime, without the use of JCN, e.g. plugging them into reserved attributes on the logical message tree... this way developers would be able to map these credentials flexibly for any number of current and/or future use cases.
Hi Roberto, just following up on the comment above to see if you could help clarify the use case further please. For now I'll move the request to Future Consideration, but without further info there is a good chance this idea will be rejected in later house keeping exercises.
Hi Roberto. Thank you for taking the time to raise this enhancement request and apologies for the time taken to respond. As written, I'm afraid we're struggling to understand the specific request here. In general security profiles are used in situations where deeper configuration is required than "just use a security identity to authenticate an inbound query to a flow". In some situations the security profile could of course also be something pretty simple like turning on HTTP Basic Auth. Is there a specific usecase that you would like to see for a Security Profile? OAuth was mentioned and we do have a long standing desire to add native OAuth support to ACE which is covered under other ideas (eg APPC-I-199 and APPC-I-360). Or was your thinking about some other security model or a specific transport / use in conjunction with a particular flow node type? Or possibly you were thinking about some kind of extended usecase around letting flow developers have access to information in the security profile in a similar way that we now allow JCN code to access credentials?