Jump to content
karel_janecek

An Authentication object was not found in the SecurityContext

Recommended Posts

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

Share this post


Link to post

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

Share this post


Link to post

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.

Share this post


Link to post

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

Share this post


Link to post

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

 

Share this post


Link to post

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.

Share this post


Link to post

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

Share this post


Link to post

You can easily find my email in ICS source code.

Share this post


Link to post

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

Share this post


Link to post

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

 

Share this post


Link to post

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

Share this post


Link to post
Posted (edited)

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 by FPiette

Share this post


Link to post

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

  • Like 1

Share this post


Link to post

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

Share this post


Link to post

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

 

  • Like 1

Share this post


Link to post

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

 

 

Share this post


Link to post

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

Share this post


Link to post

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

 

Karel

Share this post


Link to post

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

 

Share this post


Link to post

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

Share this post


Link to post
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.

Share this post


Link to post

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

Share this post


Link to post
Posted (edited)

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 by Angus Robertson

Share this post


Link to post

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×