nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Basic Authentication/Network Credential not transmitted

TimScheiber

Hi, I'm facing an issue when trying to display a secured WMS Layer on my Map.
The Service is secured and I want to authorize using basic authorization.

After loading the WMS-Layer I get an error because I'm "Unauthorized", although I handled the Authorization Challenge correctly.

After analyzing HTTP-Traffic, this is what I found:

Most of the time, Username and Password are not present in the Authorization Header after my Auth-Challenge Method was called:
Header: Authorization: Basic Og== ('Og==' is just ':' Base64 encoded)

Sometimes (like 1 in 10) the header is set correctly: Authorization: Basic {username:password, base64}

ServiceUri has be be correct because when i change it there is no Authorization-Header at all.

This is my CreateCredentialAsync-Method:

public Task<Credential> CreateCredentialAsync(CredentialRequestInfo requestInfo)
{
    return Task.FromResult((Credential) new ArcGISNetworkCredential("https://myService.com/something",
        "username", "password"));
}

Normally I'd have to load the credentials asynchronously, but ArcGIS behaves the same with this simplified CreateCredentialAsync Method.

I'm using ArcGIS Runtime 200.6

Could this be an issue within the ArcGIS SDK?

Thanks for any help

Vind meer berichten getagd met

NET 6+

Windows

WinUI

Accepted answers

MatveiStefarov

@TimScheiber Good news! Geoportal support helped set up a debugging environment and I was finally able to reproduce the issue. I believe the root cause is a bug in .NET itself, which I just logged: SocketsHttpHandler retries with useless "Authorization" header when SystemNetworkCredential is in use · Issue #113145 · dotnet/runtime

For now, you should be able to work around this problem by setting PreAuthenticateBehavior property to "Always" on your ArcGISNetworkCredential.

I will also try to add an automatic workaround to Maps SDK in the next release, and hopefully Microsoft will eventually patch the underlying issue.

All comments

TimScheiber

Thank you for helping resolve my issue. PreAuthenticateBehavior "Always" works for me!

MatveiStefarov

For now, you should be able to work around this problem by setting PreAuthenticateBehavior property to "Always" on your ArcGISNetworkCredential.

I will also try to add an automatic workaround to Maps SDK in the next release, and hopefully Microsoft will eventually patch the underlying issue.

MatveiStefarov

I have been trying to reproduce the issue locally, but so far unsuccessfully. It is possible that a problem exists in the way we parse headers, handle pre-authentication, cache unauthenticated URLs, pattern-match URLs, or handle HTTP Basic realms. However, I could not get very far with debugging without any valid credentials.

I now contacted GEOINFO Applications AG (who run Geoportal) and they are helping me create a temporary unprivileged account, just to test authentication. I will keep you posted about progress of my investigation.

Meanwhile, could you check if changing PreAuthenticateBehavior property for the credential to "AfterFirstChallenge" or "Always" helps?

TimScheiber

Hi Matvei! Thank you for looking into my issue.

This is the Service I am trying to integrate: https://www.geoportal.ch/services/wms/benken/wasserkorporation_benken/authenticate
The URL always has the same protocol (HTTPS) and does not include an irregular port number. Capitalization shouldn't matter either.

I'm using WinUI (NuGet: Esri.ArcGISRuntime.WinUI, Version 200.6.0)

Somehow the ChallengeHandler is called as expected, but the credentials are still missing in the following HTTP Requests, no matter the credentials. (Header Authorization: Basic Og==)

The credential is added via a ChallengeHandler as described in my original Post. I tried creating the credentials statically and instantly returning them but ultimately need to load the credentials asynchronously. This does not make a difference.
I have also tried to configure the credential upfront and that does seem to work but it does not resolve my issue because my Services and Layers are not static but configurable.

MatveiStefarov

Hello Tim! Thank you for bringing this problem to our attention. I've been trying to get to the bottom of this, but was not able to reproduce it yet. I created a little self-contained HTTP server for testing, that responds with lowercase "www-authenticate" header: HttpBasicResponder · GitHub

I tested making requests to this service using the latest version of Maps SDK on different platforms -- Windows desktop, UWP, iOS, Android. They all seem to call the ChallengeHandler as expected, and succeed when I provide an ArcGISNetworkCredential.

Could you tell me more about your setup please? Here is some information that may help me find the cause:

Is the ArcGISNetworkCredential added up-front, via a ChallengeHandler, or loaded from persistence/JSON?
Which platform is your software targeting -- .NET Framework, UWP, .NET 8 on Windows, Android, iOS, or Mac Catalyst?
Does the ServiceURL of the credential have the same protocol as the service (HTTP vs HTTPS)?
Does the ServiceURL of the credential include a port number, or any part of the path, or any part of the query for the service? If it includes a path, does capitalization match?

SomeGISGuy

Instead of relying on the callback, could you try just creating the credential and adding it up front to the AuthenticationManager prior to adding the layer?

TimScheiber

Sadly this doesn't resolve my issue. I have OAuth Client Credentials set up and working for different services, but I'm trying to use Basic Authorization for this specific service.

After further investigation, I have found the issue. The WWW-Authenticate Header is not detected by the ArcGIS Framework, because it is transmitted lowercase: www-authenticate: Basic realm="xyz".

When I intercept HTTP Traffic and change the Header to be uppercase, (WWW-Authenticate ...) authentication works as excpected.

HTTP Headers should be detected as case-insensitive: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers

This is only an issue since Version 200.x, 100.x worked fine in this regard

KarenRobine1

This sample may work for you: https://developers.arcgis.com/net/security-and-authentication/tutorials/access-services-with-oauth-2-0/.

Keep in mind, some of that code in there is Obsolete. I'm hoping they update that sample (and the MAUI sample) soon.

Also, you can't use the same authentication ClientId, RedirectURL for multiple applications I believe. I'm also currently unable to get it working in 200.6 but the application I'm trying this on is different from the one I'm using for an app with 200.4 on it. It's quite possible I setup the authentication incorrectly. I need to go back and update my working 200.4 app to 200.6 to see if that works. I'll let you know my results.

Doe mee aan het gesprek

Aangemelde leden kunnen berichten plaatsen, updates volgen en meer. Nieuw hier? Registreer een gratis account.

Snelle Links

Community Help
Find useful guides, FAQs, and documents to help you navigate and make the most of Esri Community.