Expose SspiAuthenticationParameters on SspiContextProvider

[twsouthwick]

This change updates the SSPI context provider to surface information to implementers via SqlAuthenticationParameters.

This also expands #2559 to loop through all SPNs in the base SSPIContextProvider rather than just a specific implementation.

Part of #2253

[codecov]

Codecov Report

Attention: Patch coverage is 79.31034% with 12 lines in your changes missing coverage. Please review.

Project coverage is 61.43%. Comparing base (17621da) to head (f7c90b4).
Report is 1 commits behind head on main.

Files with missing lines	Patch %	Lines
...crosoft/Data/SqlClient/SSPI/SspiContextProvider.cs	75.00%	8 Missing ⚠️
.../netcore/src/Microsoft/Data/SqlClient/TdsParser.cs	0.00%	1 Missing ⚠️
...t/Data/SqlClient/SSPI/NativeSspiContextProvider.cs	66.66%	1 Missing ⚠️
...ata/SqlClient/SSPI/NegotiateSspiContextProvider.cs	88.88%	1 Missing ⚠️
...ata/SqlClient/SSPI/SspiAuthenticationParameters.cs	88.88%	1 Missing ⚠️

❗ There is a different number of reports uploaded between BASE (17621da) and HEAD (f7c90b4). Click for more details.

HEAD has 1 upload less than BASE

Flag	BASE (17621da)	HEAD (f7c90b4)
addons	1	0

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #2454      +/-   ##
==========================================
- Coverage   67.03%   61.43%   -5.61%     
==========================================
  Files         299      294       -5     
  Lines       65497    65207     -290     
==========================================
- Hits        43907    40057    -3850     
- Misses      21590    25150    +3560     

Flag	Coverage Δ
addons	?
netcore	66.63% <73.21%> (-5.58%)	⬇️
netfx	59.57% <65.21%> (-5.55%)	⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[twsouthwick]

@mdaigle next step for sspi :)

[twsouthwick]

ping @mdaigle @cheenamalhotra

[mdaigle]

Hey @twsouthwick, I'll try to take a look at this today!

[twsouthwick]

The errors appear to also be on main and are an "Access denied" for something related to certificates. It doesn't appear to be caused by my change, but let me know if you believe it is.

[mdaigle]

I think this all makes sense to me. I'll take another look tomorrow and also see why the tests are failing.

[mdaigle]

Tests should be green now. We had a build agent issue that was resolved yesterday.

[mdaigle]

I'm trying to think of the best way to populate this. In other usage, I see serverSpn getting set as the resource and dataSource getting set as the serverName. I think it makes sense to continue that pattern here given that serverName and server SPN may be different.

[mdaigle]

SqlClient/src/Microsoft.Data.SqlClient/netcore/src/Microsoft/Data/SqlClient/SqlInternalConnectionTds.cs

Line 2437 in e0fa87b

var authParamsBuilder = new SqlAuthenticationParameters.Builder(

[mdaigle]

I'm also not sure how to feel about authority. In federated auth, it's assumed that authority will be present, but here we don't set a value.

Let me chat with the team to see if we'd prefer to create a new type to better represent this set of credentials.

[twsouthwick]

Sounds good. I refactored the builder so that the same pattern can be had wherever it's used if we want to use the existing SqlAuthenticationParameters

[vonzshik]

I'm probably missing something, but from my understanding SspiContextProvider attempts to generate sspi context by iterating over each serverSpns (which is passed via authParams.Resource). But because _negotiateAuth is cached here, if it fails for the first spn, it's also going to fail for the others since it's going to be the exact same spn.

[mdaigle]

You're right, nice catch! The implementation used to reset _negotiateAuth to null if authentication failed, but that's missing now. @twsouthwick can we correct it in a follow up PR?

[twsouthwick]

Will do - good catch. I'll open a separate PR for that.

The looping was added independently of the work I've been doing, so I'm not fully aware of how it's expected to work.

It opens a question as to the design I've moved this to - if we have a list of SPNs, what's the expected outcome? I think things will be just fine if it's the first SPN that completes the SSPI handshake. However if it's the second, on subsequent attempts it will be trying the first again. I can update the SspiContextProvider base to keep track of what was the successfull SPN to only submit that on subsequent calls.

[twsouthwick]

Here's the PR to add that back: #3347