IBM Sustainability Software - Ideas Portal
This portal is to open public enhancement requests against the products and services belonging to IBM Sustainability Software. 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 Eric,
Thank you, this helps clarify the scenario.
So the main requirement is to support a token generation endpoint that is completely independent from the Map Service URL, including a different domain/host.
In other words, instead of deriving or assuming the token URL from the Map Service endpoint, the configuration would need to allow an explicitly defined token URL, such as:
Token URL:
https://mytokens.onpremserver.net/getMyToken
Map Service URL:
https://mymapservice:12345/MapService/
One follow-up question: is the token URL in your example a standard ArcGIS token endpoint, or is it a custom/proxy token service used in your environment?
That distinction will help us better understand whether this is an ArcGIS configuration pattern or a customer-specific authentication/proxy setup.
It essentially came down to wanting to use two entirely different domains for the token and the map service, which the current configuration doesn't allow.
For example:
https://mytokens.onpremserver.net/getMyToken
https://mymapservice:12345/MapService/
Hope that helps!!
Regards,
Eric H.
Just checking in regarding the information requested below. We are still interested in understanding the scenario in your environment where the Map Service URL and the token generation URL are different.
Whenever you have a moment, could you please provide a bit more detail on how this is configured on your side and how the token endpoint is resolved when consuming the same secured services directly through ESRI applications (such as ArcGIS Online or ArcGIS Enterprise Web Maps)?
This information will help us better evaluate the idea and understand the underlying use case.
Thank you for reaching out and for sharing this idea.
In your environment, can you please describe the scenario where the Map Service URL and the token generation URL are different?
Specifically, what causes these two endpoints to be exposed as separate URLs?
When you consume the same secured services directly in ESRI applications (such as ArcGIS Online or ArcGIS Enterprise Web Maps),
How is the token endpoint resolved in that case?
Is the token URL explicitly configured, or is it automatically derived by the ESRI platform?