[SERVER-8801] Support multiple concurrent authentication requests on a single connection. Created: 01/Mar/13  Updated: 06/Dec/22

Status: Backlog
Project: Core Server
Component/s: Security
Affects Version/s: 2.4.0-rc1
Fix Version/s: None

Type: Improvement Priority: Minor - P4
Reporter: Robert Moore Assignee: Backlog - Security Team
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Any


Assigned Teams:
Server Security
Participants:

 Description   

With the upgraded security features in 2.4, specifically delegating authentication credentials to different databases/sources, all drivers must now ensure that all credentials provided by the application are asserted for each connection prior to submitting any application requests. The driver has lost visibility into what requests need which credentials.

Prior to the delegate credentials drivers could lazy interleave authentication request between other messages and simply ensure that the database a user was accessing already had its credentials asserted on the connection. Using this model the driver only had to assert a single set of credentials before using the connection for the application's requests.

In the new security world, it should be possible for the drivers to pipeline the all of the commands to start all of the credential assertions and then handle the responses to the requests as they are returned from the server. This could significantly reduce the initial connection latency when there is a large number of credentials to assert or there is a high latency connection from the client to the server.

Currently the ClientBasic only supports a single AuthenticationSession making pipelined authentication requests impossible as each authentication start message clobbers the previous start. This should be changed to maintain a set of AuthenticationSessions.



 Comments   
Comment by Robert Moore [ 03/Mar/13 ]

Interesting conundrum. I can see (and had not thought about) the need to keep a bad actor from connecting and performing a denial of service attack but consuming more and more memory without ever actually authenticating to the server.

I think it would be reasonable to limit the number of outstanding authorization requests to a small number (more later, on a value for small) until at least 1 authentication attempt works and then removing the limit. At that point we either have a valid user or a bad actor that has many more ways to destroy the server so keeping our finger in this particular crack probably makes little sense. It would be nice if client side SSL certificate authentication counted as the first authentication.

On small. My goal in this ticket was to cut the round trip time to get a connection "working". If that is the case we can probably even keep "small" very small. We can probably assume that the distribution of clients using N credentials looks something like: 1 - 90%, 2 - 9%, 3 - 0.9%, ... At 3 we have 99.9% of the population (in my completely made up distribution) and we only help an ever decreasing segment of the population by picking a larger number.

So the question is, What does the distribution really look like? If we know or can find out then we can pick a value that covers whatever segment of the population is desirable. If we don't know and can't find out then I'd say pick something like 10 and assume it covers the vast majority of users based on an argument that the distribution probably looks similar to above.

Comment by Andy Schwerin [ 01/Mar/13 ]

The current design is intentional, to limit the amount of intermediate state that a client can force a server to hold onto. However the choice of exactly one conversation at a time was somewhat arbitrary. Although the current wire protocol doesn't allow responses to come back out of order, there is still an opportunity to eliminate bubbles in the network by pipelining, as the reporter mentioned.

So the question that has to be answered if we decide to change this behavior is how many simultaneous authentications should we allow to be in progress on a single connection?

Comment by Andy Schwerin [ 01/Mar/13 ]

Closed in error. This is not the same as SERVER-8157.

Comment by Scott Hernandez (Inactive) [ 01/Mar/13 ]

see SERVER-8157

Generated at Thu Feb 08 03:18:29 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.