An Authentication object was not found in the SecurityContext

[karel_janecek 1]

Greetings from the Czech republic,

 

let me discuss a strange behavior of TSSLHttpCli component.

 

I address certain URL using username+password authentication, HTTPS. If I enter URL plus credentials using SopaUI and pass the request then, the appropriate response is returned properly.

If I do the same steps using ICS TSSLHttpCli component, an error message is returned from the server:

 

HTTP Status 401 Unauthorized
------------------------------------
Type Status Report

Message An Authentication object was not found in the SecurityContext

Description The request has not been applied because it lacks valid authentication credentials for the target resource.
------------------------------------
Apache Tomcat/8.5.69

 

TSSLHttpCli component has TSslSecurityContext assigned, credentials are placed into Username and Password properties of TSSHttpCli component. I've been using the latest version of ICS, problem occurs with both versions of OpenSSL libraries.

 

Could anyone tell me what is wrong? Thank you!

 

Karel

[Angus Robertson 574]

The response from the server is slightly misleading, context does not refer to the ICS context component, but to the server itself being unable to authenticate the request, thus the 401 error. 

 

So the real error could be a bad login or password, or the server requires authentication in a different way to the clear text basic authentication you are using, which is rare in the modern world. 

 

Angus

[FPiette 382]

In addition to what Angus said, it is possible that the web server make use of cookies and you must handle those properly.

 

A way to debug the issue is to use WireShark to spy on the dialog between SopaUI and the server, and then on the dialog between you ICS powered application and the server. Looking at the differences will surely help.

[karel_janecek 1]

Greetings, thank you for your response and advices. I caught the communication in both cases (SoapUI and my app powered by ICS) and here are the results:

 

SoapUI: I see two consequent requests, first one returns authorization which is used in the second request's header then.

My app: Only first request is sent and the process stops because of unauthorized. No second request.

 

I enclosed the appropriate files that illustrate the content of particular requests and responses. Is the requested behavior a matter of settings certain properties of SSLSecurityContext?

 

Thank you for any help.

 

All the best,

 

Karel

Yamaco1response.txt

Yamaco1request.txt

Sopaui2response.txt

Sopaui2request.txt

Sopaui1response.txt

Sopaui1request.txt

[Angus Robertson 574]

No idea what order you are making those requests, but you only send authentication in Sopaui2request.txt  which works fine. 

 

Authentication has nothing to so with TSslContext. 

 

Angus

 

[FPiette 382]

In your Yamaco1request.txt, I don't see the the same http header lines, including Authorization which is at least needed. Your code is wrong. Please post a complete, small, minimalist example of code which reproduce the problem you have.

[karel_janecek 1]

Thank you, I'm able to provide fully functional small example shortly but I'm not entitled to publish credentials for mentioned testing service.

Would you be so kind and could you send me (my e-mail is yamaco@yamaco.cz) the e-mail address which I can use for sending example and credentials?

 

Thank you.

 

Karel

[FPiette 382]

You can easily find my email in ICS source code.

[karel_janecek 1]

Great, I have created the sample and just sent it to you.

 

Thank you!

 

Karel

[FPiette 382]

You should also publish your sample here, greying out (but not remove) any credential information.

[Angus Robertson 574]

Can you please confirm you are using ICS V8.69?  I did a major rewrite of Digest authentication in that version to support modern standards, including adding authentication to the three main HTTP client samples and extensive testing with ICS servers, but not Apache.

 

Angus

 

[karel_janecek 1]

Hello, yes, I have version 8.69 installed. As Francois advised me to check ServAuth because of the suspicion of change the authenticvation method on new instance of TomCat, I tried to do this but an error message (List index of bounds(0)) appears (in procedure THttpCli.TriggerRequestDone2).

 

I'm very grateful for your help, thank you!

 

Karel

[karel_janecek 1]

Based on Francois's recommendation, I posted the concerned sample of code here.

 

Karel

HTTPCli.zip

[FPiette 382]

I can confirm that using ICS demo OverbyteIcsHttpsTst.dproj, the authentification works correctly (Using the credentials that has been sent to me) and the request is sent correctly.

The server response with a "server fault", probably because of an incorrect request. The error message is in Czech and I don't read that language.

 

I noticed that the server requires TLSV1.2 or TLSV1.3, nothing else.

 

Now Karel should start from the demo and remove any code he doesn't need, step by step, checking each step to see if he removed something required.

Edited June 30, 2022 by FPiette

[karel_janecek 1]

Greetings,

 

thank you for providing this information, I did the compariosn I have just discovered the reason of the issue.

 

When I set HCSSL1.Connection:='Keep-Alive', authorization started to work properly.

 

It's been probably some change in authorization process towards new version of Tomcat, because contemporary version worked well even without setting this property.

 

Francois and Angus, thank you for you efficient help and have a great weekend ahead.

 

Karel

[karel_janecek 1]

Greetings, I apologize but I must go back to the topic above. It seems that something wrong is in the last version 8.69.

 

As I informed, using HTTPS within  TSSLHttpCli works properly. However, if I try to connect using the same component (with httpAuthNone set) via HTTP, this message is returned:

 

<!doctype html><html lang="en"><head><title>HTTP Status 401 - Unauthorized</title><style type="text/css">body {font-family:Tahoma,Arial,sans-serif;} h1, h2, h3, b {color:white;background-color:#525D76;} h1 {font-size:22px;} h2 {font-size:16px;} h3 {font-size:14px;} p {font-size:12px;} a {color:black;} .line {height:1px;background-color:#525D76;border:none;}</style></head><body><h1>H

TTP Status 401 - Unauthorized</h1><hr class="line" /><p><b>Type</b> Status Report</p><p><b>Message</b> An Authentication object was not found in the SecurityContext</p><p><b>Description</b> The request has not been applied because it lacks valid authentication credentials for the target resource.</p><hr class="line" /><h3>Apache Tomcat/8.5.79</h3></body></html>

 

Important: If I compile my app without ANY change in code but with version 8.67, connection passes properly.

 

Could you inspect whether there is any bug regarding this in 8.69 version?

 

For the time being, I'll continue with 8.67 version, no problem.

 

Thank you!

 

Karel

[Angus Robertson 574]

If you want me to investigate a possible authentication issue, I'll need a failing example to test, my private email is in the ICS source code files, specifically a URL and login that works and fails, not interested in any source code.

 

Angus

 

[karel_janecek 1]

Hello Angus,

 

thank you for your willingness. I'd be glad to provide you all requested information but they will be useless for you - mentioned HTTP/HTTPS  instances are operating inside some of Czech municipality organisations so they are not exposed to the public Internet.

 

It's completely out of my hand, I'm sorry.

 

Karel

 

 

[Angus Robertson 574]

If I can not reproduce a problem, I can not fix it.  You will need to reproduce using a public server.  

 

Or against the ICS web server sample which supports all authentication methods.

 

Angus

[karel_janecek 1]

I fully understand but unable to do it. Will a full logfile created using ICSLogger be useful for you for the investigation?

 

Karel

[Angus Robertson 574]

The IcsLogger is designed for low level SSL development, not application protocol debugging. 

 

Try reproducing the problem using the OverbyteIcsHttpRestTst sample with debug logging set to HTTP headers and set a log directory, then send the complete log, not selected extracts, indicating where it fails.  If you can not reproduce the bug in that sample in V8.69, the problem is your code.

 

Angus

 

[karel_janecek 1]

Thanks Angus,

 

I have arranged trying out  OverbyteIcsHttpRestTst sample app by one of our customers on Monday and I'll send you the logfile then.

 

Karel

[Fr0sT.Brutal 900]

On 7/21/2022 at 4:38 PM, Angus Robertson said:

If you want me to investigate a possible authentication issue, I'll need a failing example to test, my private email is in the ICS source code files, specifically a URL and login that works and fails, not interested in any source code.

Probably full traffic dump made by WireShark?

On 7/21/2022 at 6:08 PM, Angus Robertson said:

The IcsLogger is designed for low level SSL development, not application protocol debugging.

Hmm, I see this assertion periodically but still can't get why. Logger is very nice and is used by ICS for event reporting of various levels. I've loaded it additionally with all channel-related stuff in my project and it does well.

[karel_janecek 1]

Hello Angus,

 

I performed an OverByteIcsHttprestTst run and the result is one and the same as our app using version 869 provides, i.e. with authentication error.

Our app on the same machine compiled with 867 version works well so I think problem will be somewhere else, not in our app.

 

The log is attached.

 

P.S: It's a state-driven municipality office and no-one allows me to install Wireshark or anything else there, I apologize.

 

Thank you for any comment or help.

 

Karel

 

 

log.txt

[Angus Robertson 574]

The log shows a single un-authenticated request resulting in a 401 response, no attempt to send authentication or repeat the request.  The sample would have brought up a dialog box asking for a password to be entered and repeated the request.  

 

Sorry, but there is no point in posting logs that don't illustrate any real activity or problems. 

 

BTW, beware of posting real authentication details in an open conference. 

 

Angus

 

Edited July 25, 2022 by Angus Robertson