We have a web application developed which has some GIS Modules.
We are authenticating users through AD. The problem is we must ask the internet user to log in again while using GIS modules even though the user is already logged in to our application. Neither we want to use JavaScript to log in to prevent exposing credentials on the network.
it will be good if we can generate tokens for AD-like server-tier authentication.
Optionally ESRI can think of providing an option to generate token for a key (to restrict token to be use with other application) and the caller will provide details about user, validity etc on secure.
This can give the option to the developer to authenticate and authorize using any possible way e.g. DB a, AD ,Azure etc authentication and authorization. Which will ease ESRI integration with any technology e.g. in our case Asp .NET MVC with ESRI JavaScript API.
So Application is responsible for authenticate and authorize and to provide details to ArcGIS server to generate token and ArcGIS server is responsible to validate token on each service request.
Typically we've used this:
https://developers.arcgis.com/javascript/3/jshelp/ags_proxy.html
over the years. It's embedded into your applications' web server. It's available and secured by IWA/AD and then injects a credential that allows the user to authenticate to the GIS. It doesn't work in every case but if you're using the old-school IWA/AD authentication types, then this is a good solution.
Personally, I'd prefer people to use SAML2 rather than IWA. It natively gets closer to what you're trying to achive as it's aligned with the internet, whereas AD is more intranet.
Have a look see if it helps you?
I implemented the proxy and its working as expected but here is the catch.
My application and GIS server is not the same server hence proxy downloads the response and writes it back to the client which is taking time. As the number of users increases, the more performance issue I am facing.
😞
Now trying to find solutions to improve performance.
That’s a much bigger subject and lots and lots of reasons for potential performance issues. That normally leads into a health check (with my local clients) which can take a few days.
I’m glad you got the first step working. Good luck with the rest of the app.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.