Support for Integrated Windows Authentication in Portal for ArcGIS

[jmirmelstein]

More often than not, Portal for ArcGIS implementations are done using Integrated Windows Authentication. Support for IWA in authenticating against a Portal would be a fantastic addition to this tool!

[dannykrouk]

I agree with Jeremy. I actually thought that I had this working before with Portal and IWA. But, I definitely cannot get it working now. What i notice is that it seems to have trouble finding the /sharing/rest/content/users/xxxx endpoints because it doesn't construct the username part of the url correctly. Secondarily, it seems to get a little confused around authentication ... when it succeeds, it usually ends up making two different token requests (with the same parameters). At any rate, consider this another vote for this feature.

[lpsnyd]

I was trying this today and thought about a workaround. I temporarily disabled windows authentication and enabled anonymous authentication in IIS on my portal directory. Then I used my portal admin login to sign into the ago assistant. This worked, only after moving an item to my admin user. I was able to log in and the item appeared for JSON inspection and url update. I tried again but didnt document the portal url so couldn't immediately replicate. Since it was at the end of business hours, i didnt have much time. I then switched authentication back and will test again another time.

Are there possibly any other ideas? I had to do something similar with IIS authentication for running the activity dashboard.

[jmirmelstein]

@lpsnyd This is generally an issue at organizations that have a firewall in place blocking direct access to the Portal for ArcGIS over Port 7443. In these organizations, the only way to truly authenticate into the Portal (or Activity Dashboard) is over HTTPS using IWA.

[dolmaron]

I just wanted to open this can of worms and see if anyone has any update. I just deployed Ago-Assistant internally and didn't find this open issue until after I had played around with it a little. My issue is that I can't login when IWA is enabled on the portal... and then if I change it to anonymous I don't get any results in the Root folder for the portal in the display. (signed in with the default admin account)

[ecaldwell]

I haven't made any attempts yet. I don't really know where to start. Can anybody shed some light on how access works when IWA is enabled? It's different than enterprise logins right? Is there a certificate that gets passed to Portal?

@dolmaron When you signed in with the default admin account, could you modify the search dropdown to look at all content in your Portal and find things that way?

[ecaldwell]

I think I have the approach now (@olearydw set me straight). There's a session cookie that Portal sets once you're authenticated. I need to basically rip out the OAuth handler in favor of a handler for that cookie. I'll work on putting up a separate branch that you can deploy with your Portal to test. Stay tuned.

[lpsnyd]

This would be a great enhancement!

[dolmaron]

@ecaldwell I would greatly appreciate that. Let me know if you would like me to test anything in response to your updates.

[ecaldwell]

I pushed up a new branch to test with on my fork. Can you download that version, change line 105 in js/main.js to reflect your domain and then deploy on the same domain as your Portal. Sign into your Portal, then open this app and see if it works.

[dolmaron]

Testing it now

[dolmaron]

Ok, at first it was not working, but I was able to find the issue. It looks like there was a leftover handle in the logic of main.js on line 102 for some testing that was being done. The value of cookie("test") was in there for the JSON.parse. After looking at this I changed it to

    // Check if the user has already authenticated with IWA.
    if (cookie("esri_auth")) {
        var esri_auth = JSON.parse(cookie("esri_auth"));

instead of

    // Check if the user has already authenticated with IWA.
    if (cookie("esri_auth")) {
        var esri_auth = JSON.parse(cookie("test"));

So now the login appears to be working. I will test functionality tomorrow to confirm everything is working as expected. Thanks for this update.

[ecaldwell]

Good catch. Thought I had gotten the test variable swapped out, but obviously not! Most stuff should work, but copying content may not. That may take some extra handling. Let me know what you see.

[dolmaron]

So far so good on behavior, unfortunately one of the major items I was planning on using the AGO assistant for is for moving data between two portals, one here in the US and one in the UK. I have tested this behavior and it does appear to fail when attempting to log into the UK portal.

As a side note, how does the AGO Assistant handle moving a portal item between two portals when the service behind the portal item is coming from a federated ArcGIS Server?

[ecaldwell]

Good news, there is a much simpler approach to implementing this support. The cookie finding is unnecessary. The IWA and PKI authentication can be handled and captured with the initial call to self which was already implemented for URL validation. This call fires off the web authentication for IWA and PKI portals. I plan to push up the change in the next several days for you all to test.

There are several benefits to the new approach:

• doesn't require a separate code branch
• will allow use of the app even when the app is hosted on a different domain than the portals (including the existing cloud hosted version)
• will allow for authenticating with two different enterprise auth portals in the same session (e.g. copying from an IWA secured portal to a PKI secured portal)

[jmirmelstein]

We're having trouble making calls to the self resource as a result of it being secured with IWA. When accessed directly from a browser, there is an authorization header attached to the request. But this header is never created when the call is initiated from the AGO Assistant. Furthermore, I see this call to the self resource in Chrome, but not IE11.

[ecaldwell]

Alright, thanks to some extreme hand holding from @rwmajor2 I pushed up a new branch that has a different (and hopefully better) approach. It's on the develop branch in my fork. You can also give it a swing from the staging site. There should no longer be a need to download and host it locally, unless your portal and client browser are behind a firewall.

Let me know where it breaks.

[ecaldwell]

Here's some detail on what I'm expecting to happen.

Entering the URL to a PKI or IWA secured portal should automatically kick off web tier authentication (this is due to a URL validation step that makes a call to the portal's sharing/rest endpoint to check that the portal can be reached at the provided URL). Once this step has completed, there is no need to enter a username or password as they are not needed. The call to generateToken should be allowed by web tier auth. From there, a call to self with the token gets the other required values for all future calls (mainly username).

[jmirmelstein]

This new branch seems to work flawlessly! I think it's time to merge branches and buy @ecaldwell a beer or two.

[ecaldwell]

Glad it's working well for you. Let's go ahead and keep this issue open until I get the changes merged in to master.