Secured resource, error 401

[AndriyFedin]

I'm trying to create AGSFeatureLayer from an URL. The resource is under authentication, so I pass a token to AGSServiceFeatureTable object using AGSRequestConfiguration. In our project we have a couple of environments and for one of them it works fine, but for the other one i'm getting an alert:
"<NDA_domain.com> requires a client certificate"
"Would you like to browse for the certificate to connect to this host?"

I was also able to extract the following error using AGSAuthenticationManagerDelegate:

Error Domain=com.esri.arcgis.runtime.services.error Code=401 "Credential Required" UserInfo={NSURL=https://<NDA_domain.com>/FeatureServer/4, NSLocalizedDescription=Credential Required, protectionSpace=<NSURLProtectionSpace: 0x600000980f10>: Host:<NDA_domain.com>, Server:https, Auth-Scheme:NSURLAuthenticationMethodClientCertificate, Realm:(null), Port:443, Proxy:NO, Proxy-Type:(null)}

Other errors in console look like this:

Connection 4: TLS Client Certificates encountered error 1:89

Connection 4: encountered error(1:89)

[boringssl] boringssl_context_handle_fatal_alert(1967) [C4.3.1:2][0x137dd7c90] write alert, level: fatal, description: certificate unknown

[boringssl] boringssl_context_error_print(1957) [C4.3.1:2][0x137dd7c90] Error: 5256693112:error:1000007d:SSL routines:OPENSSL_internal:CERTIFICATE_VERIFY_FAILED:/Library/Caches/com.apple.xbs/Sources/boringssl/ssl/handshake.cc:419:

[boringssl] boringssl_session_handshake_incomplete(86) [C4.3.1:2][0x137dd7c90] SSL library error

Some more details.

When I try to load the url using URLSession, it works well every time. I'm also able to load the resource successfully in a browser (including iOS Safari). And it works well in Postman.

When I try to monitor requests with proxy tools like Proxyman, for some reason the 401 error disappears. 

I also tried using AGSAuthenticationManagerDelegate, to fix the issue in
-authenticationManager:didReceiveAuthenticationChallenge:
by creating AGSCredential with the same auth token, but I had partial success: the didReceive challenge method keeps being invoked with the new Code=498 "Invalid token" error and when I try to load the resource a couple more times it actually loads successfully at some point. But it's not the best result with all those errors.

So the main questions are:

Where Auth-Scheme:NSURLAuthenticationMethodClientCertificate is coming from? And how to get rid of this Certificate authentication attempt?

[MarkDostal]

Hello, sorry to hear you are having issues.  Which method(s) are you using to create the AGSFeatureLayer?  If you're using an `AGSServiceFeatureTable` to create the layer, you can simply set a credential on it, so you don't have to mess with tokens or anything else.  If the service can be authenticated on different environments, then you should be all set.

`AGSServiceFeatureTable` inherits from `AGSRemoteResource`.  That protocol has a `credential` property that you can use to prevent authentication challenges from being displayed to the user (provided the credential is valid for the resource you're trying to access).  All classes that inherit from `AGSRemoteResource` operate that way.

Give that a try and if it doesn't work I'll be more than happy to dig into it further with you.

-Mark

[AndriyFedin]

Hi Mark! 

Thanks for the answer!

Yes, I do create the layer using `AGSServiceFeatureTable.` But using `AGSCredential` doesn't work (I checked just in case) because we need authentication to our server. The server, in its turn, delivers layers to the ArcGIS SDK. So the token isn't for ArcGIS - it's for our app user account. I set it in the `userHeaders` property of `AGSRequestConfiguration` for ArcGIS to be able to load the layers.  

I have to update the initial details by saying that the `AGSCredential` object I use in `didReceiveAuthenticationChallenge` doesn't do anything useful. The object simply allows me to call the `continueWithCredential` function. When I set a random string to the `token` property of the object ArcGIS manages to load the resource anyway.

So to be concise:

• I try to load the layer
• I get code 401 "Credential required" in `AGSAuthenticationManagerDelegate`
• I set dummy credentials and call `continue`
• I get code 200 to the layer request
• I get code 498 exactly 7 times when layer's `/query` URL is requested
• I get code 200 to all the following requests
• the layer is not drawn on the map
• I try to load the same layer or any other one
• I get code 200 to all the following requests and the layer is drawn successfully

So I still can't understand where the `NSURLAuthenticationMethodClientCertificate` is from. 

Why does ArcGIS fail to load the resource on the first try failing with this 401 error?

And why does it work when I set a dummy credentials object and call `continue`? Looks like the client certificate isn't required eventually.

[MarkDostal]

Thank you for the clarification.  I'm going to pull in a colleague familiar with the intricacies of Authentication to help out.  One of us will reply with feedback.

-Mark

[NimeshJarecha · Accepted solution]

Hello Andriy Fedin,

Based on the error information provided, either the server or the additional security layer is engaging in the `Client Certificate` challenge. Could you please elaborate on the security setups on your environments?

Error Domain=com.esri.arcgis.runtime.services.error Code=401 "Credential Required" UserInfo={NSURL=https://<NDA_domain.com>/FeatureServer/4, NSLocalizedDescription=Credential Required, protectionSpace=<NSURLProtectionSpace: 0x600000980f10>: Host:<NDA_domain.com>, Server:https, Auth-Scheme:NSURLAuthenticationMethodClientCertificate, Realm:(null), Port:443, Proxy:NO, Proxy-Type:(null)}

Also, you can please create request log by setting properties on request configuration. You can send the log file to me directly. 

let config = AGSRequestConfiguration.global()

config.debugLogFileURL = URL(fileURLWithPath: "<path>/requestLog.md")

config.debugLogDeleteBeforeEachRun = true

config.debugLogRequests = true

config.debugLogIncludeRequestHeaders = true

config.debugLogResponses = true

config.debugLogIncludeResponseHeaders = true

Regards,

Nimesh

[AndriyFedin]

Hi Nimesh!
Thanks for your reply! Sorry I was unable to react right away.

We've been able to identify the issue with our backend team. An additional security layer on the backend indeed caused it. I can't provide more info, unfortunately. The debug log settings you mentioned were handy, though!

[NimeshJarecha]

Thanks for letting us know and glad you were able to track it down!

Regards,

Nimesh