Simplify the MDS Builder API

[abergs]

This PR aims to simplify the MDS builder API and adress some current problems we're seeing.

Developers today seems to believe it's hard / unfeasible to implement their own "caching" layer for MDS data.

• [API Proposal] Allow to disable caching for Metadata or use another cache mechanism  #550
• MetadataService/DistributedCacheMetadataService IDistributedCache dependency limitations #397

This is because we have not documented the current architecture properly, and the current builder pattern does indicate that there is not a lot of flexibility in the design, although the opposite is true.

This PR adds documentation, as well as reshapes the API to better surface the flexibility.

Example in the API change

Before

services
    .AddFido2(...)
    .AddCachedMetadataService(config =>
    {
        config.AddFidoMetadataRepository(httpClientBuilder =>
        {
            //TODO: any specific config you want for accessing the MDS
        });
    });

After:

  services
      .AddFido2(...)
      .AddFidoMetadataRepository()
      .AddCachedMetadataService();

We're also adding a two new builder methods, that makes it clear that you can register your own MDS Service to wrap the repositories, as well as custom repositories

Using FIDO mds repository + your own custom service to do caching, logging, storage, whatever

services
      .AddFido2(...)
      .AddFidoMetadataRepository()
+     .AddMetadataService<MyCustomMetadataService>();

Using a completely bespoke solution to fetch mds data and access it

services
      .AddFido2(...)
+     .AddMetadataRepository<MyCustomMetadataRepository>()
+     .AddMetadataService<MyCustomMetadataService>();

Breaking changes

This PR introduces some breaking changes in the API builder (compile time) and some run time breaking changes, namely: Removes the default registration of the NullMetadataService

• Remove the IFido2MetadataServiceBuilder
• Removes the default registration NullMetadataService

We are also adding plenty of comments as well as hiding the ConformanceMDS from Intellisense. I wonder if we should really remove it instead?

[abergs]

Please note, this PR does not actually add any new feature to the project. It does however help clarify how existing features can solve a users problem.

Does this suit your need @Simonl9l, @joegoldman2. Also curious if you have any thoughts @iamcarbon and @aseigler.

I've left it out of this PR, but I am interested in writing a FileSystemBlobRepository that sources the mds.jwt blob from the file system instead of multiple json files that the current FileSystemRepository and a "uncached" service that sits on top of it.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 78.34%. Comparing base (c0cdfc5) to head (7d8d117).
⚠️ Report is 1 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #620      +/-   ##
==========================================
+ Coverage   77.55%   78.34%   +0.79%     
==========================================
  Files          98       98              
  Lines        2539     2540       +1     
  Branches      422      422              
==========================================
+ Hits         1969     1990      +21     
+ Misses        460      440      -20     
  Partials      110      110              

☔ 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.

[abergs]

Checking in again if this solves your previous issues @Simonl9l, @joegoldman2?

[Simonl9l]

Checking in again if this solves your previous issues @Simonl9l, @joegoldman2?

@abergs we’re currently on a different path in this regard, and are no longer actively/currently using you package so defer to others.

thanks though for all you work on this package.

[joegoldman2]

@abergs this new API is more user-friendly, thank you for that. However, there is still something I don't really like and understand. The service is still strongly coupled to the cache, so it's mandatory to register IMemoryCache + IDistributedCached. Any chance we can have a version of IMetadataService without any cache mechanism and propose the cache as an opt-in feature?

[abergs]

@joegoldman2 Thanks for your response.

The service is still strongly coupled to the cache

Yes, the CachedMetadataService is strongly coupled to asp.net's caches.

You could implement a non cached version easily with the help of the documentation in this PR. The reason I don't want to ship a uncached version in the nuget package - or even encourage it - is because it's a footgun:

1. You should really only use the MDS + Attestation if you understand why you have a need for it (e.g. you work in regulated spaces)
2. If you need those security guarantees from the MDS + Attestation, you'll likely don't want your service to fall over because of the mds rate limiting or not being available. The MDS service dictates that you should rely on your caches and will rate limit you.

[joegoldman2]

It's just weird for me that the cache is at the service level and not at the store level (with a decorator for example).

[abergs]

@joegoldman2 When you say store level, you mean the repository?

Is there some naming changes we could consider to make this easer to understand?

[joegoldman2]

@joegoldman2 When you say store level, you mean the repository?

Yes, the repository sorry.