Hi there,
I've developed a UWP app using the Esri.ArcGISRuntime.UWP v100.7.0 nuget. This app connects to our Portal 10.7.1 using SAML just fine when running in Visual Studio. However, when it is deployed (two machines so far), the SAML login window in the app displays a message that it is... unable to connect to the service.
This app is working within our companies network and our Portal is using AzureAD users. Does the app need to be registered with our AzureAD as well? That is a question I've been formulating for our IT department.
What would cause the SAML WebAuth to work on my machine in VS but not in the deployed apps (Windows 10 w/ cert installed to trust app)?
Thanks!
Rich
Solved! Go to Solution.
Hi,
Unless you're testing two different environments/workflows it seems unlikely that the capabilities would explain the difference between your dev machine and the deployment machine.
It may be worthwhile taking a look at the `Enterprise Cloud Single Sign On` capability (App capability declarations - UWP applications | Microsoft Docs 😞
The enterpriseCloudSSO capability allows apps to use single sign on with Azure Active Director (AAD) resources inside a hosted web view control.
We have found with UWP that some authentication workflows don't support `WebAuthenticationBroker` and may require a custom `IOAuthAuthorizeHandler` similar to the concept implemented here for WPF: arcgis-runtime-samples-dotnet/OAuth.xaml.cs at master · Esri/arcgis-runtime-samples-dotnet · GitHub.
Regards
Mike
Hi,
What app capabilities do you have enabled?
See App capability declarations - UWP applications | Microsoft Docs particularly `Homes and work networks` (privateNetworkClientServer).
You may also need to refer to Web authentication broker - UWP applications | Microsoft Docs and the section regarding `EnablePrivateNetwork`.
Cheers
Mike
Hi Michael,
Thanks for responding... I've been swamped with several things so I apologize for the delayed response.
The capabilities that are enabled on the UWP app are...
1. Enterprise Authentication
2. Internet (Client & Server)
3. Location
4. Private Networks (Client & Server)
I'd like to be able to debug the Esri Authentication Manager to see where the request is failing, but am having issues with debugging on the device. I've been limited to debugging installed App Packages on a Remote Machine which is slow and does not provide a productive troubleshooting environment, at least I've not found a way to be productive with the debugging on the device.
When running in VS 2019 it will connect to Portal using SAML login, but on the deployed app I see the image below.
I've read the documents in the link you provided, and will look them over again in case I missed something. Enabling the logging is something I've done and will continue to look through those. If I find something useful I will post. I am thinking that I need to place some breakpoints in the Authentication Manager to see how it's use of the WebAuth Broker is being handled and if any other messages are available to describe the error.
The formatting of the redirect URI is somewhat of a question mark. I've done jsapi redirects, so this native app seems like it is different. Since it works on my laptop in VS do I need to investigate the redirect URI?
Are the App Capabilities the primary thing that would cause an app to work in VS but not when deployed?
The app is not being published to the store and is instead side-loaded onto a Dell rugged tablet. We have also deployed it using System Center to another Windows 10 machine, but the SAML Login error was the same for both instances.
Hi,
Unless you're testing two different environments/workflows it seems unlikely that the capabilities would explain the difference between your dev machine and the deployment machine.
It may be worthwhile taking a look at the `Enterprise Cloud Single Sign On` capability (App capability declarations - UWP applications | Microsoft Docs 😞
The enterpriseCloudSSO capability allows apps to use single sign on with Azure Active Director (AAD) resources inside a hosted web view control.
We have found with UWP that some authentication workflows don't support `WebAuthenticationBroker` and may require a custom `IOAuthAuthorizeHandler` similar to the concept implemented here for WPF: arcgis-runtime-samples-dotnet/OAuth.xaml.cs at master · Esri/arcgis-runtime-samples-dotnet · GitHub.
Regards
Mike
Michael,
Here is something interesting I just found online. The error message is the same as the one I have been getting.
UWP considerations (MSAL.NET) - Microsoft identity platform | Microsoft Docs
Some customers have reported the following sign-in error in specific enterprise environments in which they know that they have an internet connection and that the connection works with a public network.
We can't connect to the service you need right now. Check your network connection or try this again later.
You can avoid this issue by making sure that WAB (the underlying Windows component) allows a private network. You can do that by setting a registry key:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\authhost.exe\EnablePrivateNetwork = 00000001
For more information, see Web authentication broker - Fiddler.
You may also need to take that step (it was in the second link i provided above).
Let us know if that resolves the issue you are seeing.
Cheers
Mike
Hi Michael,
Using the WPF Sample that implements the IOAuthAuthorizeHandler, I was able to use it in UWP within a ContentDialog in a WebView and it worked.
The login process was slightly different than just using the Authentication Manager. During the final step I was prompted to entire windows credentials for our coporate login... it looked similar to UAC dialog but was connecting to login.xxxxxxx.com. Once I entered my Windows credentials, it saved and I was not prompted again. I also noticed that it is saving my previously used user profiles, which I was not seeing before.
It seems like this is the solution, at least until I gain a better understanding of how all the components work and can hopefully remove that last UAC type login prompt.
Thank you very much for you help with this. I am so happy to have something working to get maps into my app! This had been a major hurdle to deploying the app for testing.