Only call AddDataProtection in Authentication Services that require it

[eerhardt]

In .NET 8, we have a goal to enable JWT authentication with Native AOT. See Stage 2.a in #45910.

In order to use JWT authentication, the app needs to call builder.Services.AddAuthentication(). When bringing in AddAuthentication(), we are getting trimming / NativeAOT warnings from System.Security.Cryptography.Xml. System.Security.Cryptography.Xml is not currently trimming / NativeAOT compatible. See dotnet/runtime#73432. It also appears to be a major amount of work to make it compatible, possibly with many "gotchas".

The reason System.Security.Cryptography.Xml is brought into the app is because this line:

aspnetcore/src/Security/Authentication/Core/src/AuthenticationServiceCollectionExtensions.cs

Line 24 in 9c38b37

services.AddDataProtection();

DataProtection brings in the dependency on System.Security.Cryptography.Xml.

However, to enable JWT bearer authentication, it doesn't require DataProtection. Other types of authentication services do, for example:

• Cookies
• OpenIdConnect
• OAuth
• WsFederation
• Twitter
• etc

So it made sense originally to add DataProtection in a common place, and if the app didn't use it - no big deal. But now with NativeAOT and trimming, it does affect the app because the unused code can't be trimmed from the app - making it bigger unnecessarily.

To solve both the size issue (being able to trim the unused DataProtection code) and the fact that System.Security.Cryptography.Xml is not compatible with NativeAOT/trimming, we should remove AddDataProtection() from AddAuthentication() and instead move the calls to all the specific authentication services that require it.

Note that this would be a breaking change because an app could just call AddAuthentication(), without calling one of the built-in auth services, and then try to get DataProtection services, it will fail (since they aren't registered).

Alternatives

One alternative is to create a new AddAuthenticationCore() method that doesn't call AddDataProtection(), but does everything else AddAuthentication() does today.

cc @halter73 @davidfowl @JamesNK @DamianEdwards

[ghost]

Thanks for contacting us.

We're moving this issue to the .NET 8 Planning milestone for future evaluation / consideration. We would like to keep this around to collect more feedback, which can help us with prioritizing this work. We will re-evaluate this issue, during our next planning meeting(s).
If we later determine, that the issue has no community involvement, or it's very rare and low-impact issue, we will close it - so that the team can focus on more important and high impact issues.
To learn more about what to expect next and how this issue will be handled you can read more about our triage process here.

[Tratcher]

Yes, this would be breaking for most 3rd party auth providers.

AddAuthenticationCore would avoid the break, but would have to be used directly in program.cs and the template.

[eerhardt]

@Tratcher - do you have an opinion on which approach we should take?

[Tratcher]

AddAuthenticationCore has discoverability issues. How about this:

public static class AuthenticationServiceCollectionExtensions
{
    public static AuthenticationBuilder AddAuthentication(this IServiceCollection services)
    public static AuthenticationBuilder AddAuthentication(this IServiceCollection services, string defaultScheme)
    public static AuthenticationBuilder AddAuthentication(this IServiceCollection services, Action<AuthenticationOptions> configureOptions)
+   public static AuthenticationBuilder AddAuthentication(this IServiceCollection services, bool withDataProtection)
+   public static AuthenticationBuilder AddAuthentication(this IServiceCollection services, bool withDataProtection, string defaultScheme)
+   public static AuthenticationBuilder AddAuthentication(this IServiceCollection services, bool withDataProtection, Action<AuthenticationOptions> configureOptions)
}

I'd also set a bool on AuthenticationBuilder bool HasDataProtection { get; } that callers like AddOpenIdConnect would check and throw if it wasn't enabled. That way they fail at startup instead of on individual requests.

[eerhardt]

Unfortunately that proposal is not trim friendly. The trimmer is not able to see that withDataProtection is only ever passed false. See dotnet/linker#1868.

[Tratcher]

Darn. So we end up with:

public static class AuthenticationServiceCollectionExtensions
{
    public static AuthenticationBuilder AddAuthentication(this IServiceCollection services)
    public static AuthenticationBuilder AddAuthentication(this IServiceCollection services, string defaultScheme)
    public static AuthenticationBuilder AddAuthentication(this IServiceCollection services, Action<AuthenticationOptions> configureOptions)
+   public static AuthenticationBuilder AddAuthenticationCore(this IServiceCollection services)
+   public static AuthenticationBuilder AddAuthenticationCore(this IServiceCollection services, string defaultScheme)
+   public static AuthenticationBuilder AddAuthenticationCore(this IServiceCollection services, Action<AuthenticationOptions> configureOptions)
}

I'd still want that bool on AuthenticationBuilder bool HasDataProtection { get; } that callers like AddOpenIdConnect would check and throw if it wasn't enabled.

[eerhardt]

that callers like AddOpenIdConnect would check and throw if it wasn't enabled.

Why wouldn't AddOpenIdConnect just call AddDataProtection() if it needs it? Why would it require someone else to do it?

[Tratcher]

Good point 😆.

[davidfowl]

Unfortunately that proposal is not trim friendly. The trimmer is not able to see that withDataProtection is only ever passed false. See dotnet/linker#1868.

• It tightly couples the method to the implementation
• It doesn’t scale well for other things we may want to exclude

[eerhardt]

I just remembered there already is an AddAuthenticationCore method:

aspnetcore/src/Http/Authentication.Core/src/AuthenticationCoreServiceCollectionExtensions.cs

Line 19 in 3265dc6

public static IServiceCollection AddAuthenticationCore(this IServiceCollection services)

The issue with it and JwtBearer authentication is that JwtBearer also needs an ‘IAuthenticationConfigurationProvider’, which is only added by AddAuthentication.

So other options would be:

• move the default IAuthenticationConfigurationProvider service registration from AddAuthentication to AddAuthenticationCore.
• Have AddJwtBearer add the default IAuthenticationConfigurationProvider service if it hasn’t already been registered.

[danmoseley]

Aside - why do we consider System.Security.Cryptography.Xml legacy/not recommended given so many mainstream auth scenarios apparently depend on it?
Cc @vcsjones

[eerhardt]

why do we consider System.Security.Cryptography.Xml legacy/not recommended

@danmoseley - I’m not sure where you got that impression. Can you post a link?

The core of this issue is that:

1. The goal for .Net 8 is to enable JWT token auth.
2. JWT token auth doesn’t need System.Security.Cryptography.Xml
3. There’s currently no way to cut the System.Security.Cryptography.Xml code out.
4. System.Security.Cryptography.Xml has not been made compatible with trimming and native AOT. Because it is mostly by design not trim friendly. See Annotate System.Security.Cryptography.Xml for trimming runtime#73432 (comment)

[eerhardt]

why do we consider System.Security.Cryptography.Xml legacy/not recommended

Check out https://github.com/dotnet/runtime/tree/main/src/libraries/System.Security.Cryptography.Xml#readme

[JamesNK]

I'm guessing the problem with System.Security.Cryptography.Xml is there can be type names embedded in XML. For example, Type.GetType(typeNameFromXml) then is destined to fail.

DataProtection has the same kind of issues. The initial trimming annotations basically made the whole thing unsafe. Because of how fundamental DataProtection is, I refactored DataProtection annotations to a more pragmatic approach. The library works out of the box with all the applicable built-in .NET types. If there is a custom type defined in XML and it can't be found, then the error message mentions that it could have been trimmed. It didn't feel like a huge amount of work and it looks like it was successful. At least some people have been using trimming with it (they logged a bug about one place I missed 😬).

IMO System.Security.Cryptography.Xml should be annotated the same way. It works for the vast majority of people and for those doing custom things and AOT (another small number), then provide a good runtime error experience.

I brought this up before, but I think it is better to just fix the underlying cause here. At the very least, look at what is involved in fixing the underlying cause, and estimate its cost vs the cost of workaround it.

DataProtection isn't going anywhere, and for AOT to be a real thing for ASP.NET Core (i.e. generally work and not just a couple of scenarios), we'll need it to work.

[vcsjones]

Looks like @eerhardt found the most relevant link. A more opinionated answer is found here: dotnet/runtime#28599 (comment)

System.Security.Cryptography.Xml is in a state of "as dead as can be while still being technically supported". Further, the W3C shut down the XML Security WG in 2016.

I'm guessing the problem with System.Security.Cryptography.Xml is there can be type names embedded in XML

Kind of. S.S.C.Xml relies heavily on CryptoConfig, which basically maps URLs and URNs that are identifiers to types. CryptoConfig is known not to be trimming friendly:

https://github.com/dotnet/runtime/blob/ef15cfbbcebbfd8bcef2664bd6dad5c34ce66108/src/libraries/System.Security.Cryptography/src/System/Security/Cryptography/CryptoConfig.cs#L334

[davidfowl]

I brought this up before, but I think it is better to just fix the underlying cause here. At the very least, look at what is involved in fixing the underlying cause, and estimate its cost vs the cost of workaround it.
DataProtection isn't going anywhere, and for AOT to be a real thing for ASP.NET Core (i.e. generally work and not just a couple of scenarios), we'll need it to work.

Also, our new token story is currently dependent on data protection so...... +1 to what James said.

[DamianEdwards]

@JamesNK @davidfowl, to be clear, are you advocating we don't do this layering/dependencies fix for Data Protection and instead make Data Protection work for trimming/native AOT? In the case of JWT it still has size implications (JWT doesn't need it).

[JamesNK]

Yes. Put a pin on new work optimizing publish size and focus on AOT functionality.

[eerhardt]

Maybe another question to ask here (and maybe the one that @danmoseley is asking), why is DataProtection using a component that is in a state of "as dead as can be while still being technically supported"? Should we be re-thinking how DataProtection is designed?

[eerhardt]

At the very least, look at what is involved in fixing the underlying cause, and estimate its cost vs the cost of workaround it.

@jeffhandley - is it possible to get an estimate of its cost?

[eerhardt]

@JamesNK, I took a first crack at annotating the library:

dotnet/runtime@main...eerhardt:runtime:AnnotateSSCXml

Basically, almost all the APIs have added [RequiresUnreferencedCode] on them. This will let any developer who calls these APIs know that they may not (probably won't) work in a trimmed app.

There is more work to be done in that change:

• Make a good warning message
• Annotate Microsoft.Extensions.Configuration.Xml as RequiresUnreferencedCode, since it uses these APIs
• (potentially) update all the places that call CryptoHelpers.CreateFromName and throw an exception to say something like "if you are trimming an application, ensure the necessary algorithms are preserved in the app". Note there are a couple places that call CreateFromName, but just return false if null was returned. Those won't be possible to update an exception message.

What would you suggest to do with the warnings that will now be emitted from the ASP.NET code? For example:

aspnetcore/src/DataProtection/DataProtection/src/XmlEncryption/EncryptedXmlDecryptor.cs

Lines 46 to 68 in 0b10e13

	public XElement Decrypt(XElement encryptedElement)
	{
	ArgumentNullThrowHelper.ThrowIfNull(encryptedElement);
	// <EncryptedData Type="http://www.w3.org/2001/04/xmlenc#Element" xmlns="http://www.w3.org/2001/04/xmlenc#">
	// ...
	// </EncryptedData>
	// EncryptedXml works with XmlDocument, not XLinq. When we perform the conversion
	// we'll wrap the incoming element in a dummy <root /> element since encrypted XML
	// doesn't handle encrypting the root element all that well.
	var xmlDocument = new XmlDocument();
	xmlDocument.Load(new XElement("root", encryptedElement).CreateReader());
	// Perform the decryption and update the document in-place.
	var encryptedXml = new EncryptedXmlWithCertificateKeys(_options, xmlDocument);
	_decryptor.PerformPreDecryptionSetup(encryptedXml);
	encryptedXml.DecryptDocument();
	// Strip the <root /> element back off and convert the XmlDocument to an XElement.
	return XElement.Load(xmlDocument.DocumentElement!.FirstChild!.CreateNavigator()!.ReadSubtree());
	}

is now going to warn because it is using EncryptedXml.DecryptDocument() which is marked as RequiresUnreferencedCode. Are we just going to suppress these warnings in ASP.NET? It would either be that or re-mark AddDataProtection as RequiresUnreferencedCode again.

[JamesNK]

Marking AddDataProtection with RequiresUnreferencedCode isn't a good solution. It's used in so many places that huge parts of ASP.NET Core would also need to be annotated with RequiresUnreferencedCode: session, most (all?) of auth, Blazor, host builder (I believe the create default method uses it).

People have been using trimming with DataProtection in .NET 7. Whatever we do today works.

Can situations like the example below be turned into runtime errors? If DeformatterAlgorithm can't be found, then throw an error saying the name might be wrong or the type might have been trimmed.

#if NETCOREAPP
        [RequiresUnreferencedCode("CreateDeformatter is not trim compatible because the algorithm implementation referenced by DeformatterAlgorithm might be removed.")]
#endif
        public sealed override AsymmetricSignatureDeformatter CreateDeformatter(AsymmetricAlgorithm key)
        {
            var item = (AsymmetricSignatureDeformatter)CryptoConfig.CreateFromName(DeformatterAlgorithm!)!;
            item.SetKey(key);
            item.SetHashAlgorithm(DigestAlgorithm!);
            return item;
        }

This is what I did in DataProtection:

aspnetcore/src/DataProtection/DataProtection/src/TypeExtensions.cs

Lines 30 to 41 in 4190655

	[UnconditionalSuppressMessage("Trimmer", "IL2057", Justification = "Unknown type names are rarely used by apps. Handle trimmed types by providing a useful error message.")]
	public static Type GetTypeWithTrimFriendlyErrorMessage(string typeName)
	{
	try
	{
	return Type.GetType(typeName, throwOnError: true)!;
	}
	catch (TypeLoadException ex)
	{
	throw new InvalidOperationException($"Unable to load type '{typeName}'. If the app is published with trimming then this type may have been trimmed. Ensure the type's assembly is excluded from trimming.", ex);
	}
	}

I'd like a situation like DataProtection where all the built-in crypto types always work and then provide runtime errors if someone customizes the crypto types and they enable trimming.

[eerhardt]

People have been using trimming with DataProtection in .NET 7. Whatever we do today works.

We aren’t doing full trimming in ASP.NET apps. By default it uses “partial” in .NET 7.

Can situations like the example below be turned into runtime errors?

This isn’t the intent of how we are enabling AOT and trimming. If the apps behavior can change after trimming, our intention is to give the dev a warning to let them know. There are some situations where the behavior is edge case and it would be too hard (like the DI case), but here the whole library’s design is incompatible. So suppressing these warnings in dotnet/runtime isn’t going to be approved.

Would it be possible to remove EncryptedXml in DataProtection when in trimmed / NativeAOT? We could use a feature switch which devs could turn back on to add it back (with a single warning)? Or is EncryptedXml used too often for this approach to be feasible?

[davidfowl]

Would it be possible to remove EncryptedXml in DataProtection when in trimmed / NativeAOT? We could use a feature switch which devs could turn back on to add it back (with a single warning)? Or is EncryptedXml used too often for this approach to be feasible?

It's currently fundamental to the implementation. I agree with James that DataProtection needs to work with trimming. It seems like we need to take a step back and figure out exactly how much of this needs to work. This is one of the only subsystems that does things like "loads types from configuration", so it'll require more special treatment.

[eerhardt]

It seems like we need to take a step back and figure out exactly how much of this needs to work.

For our current goals for .NET 8, which is just JWT Bearer token authentication, none of it needs to work. The issue is that just calling AddAuthentication() pulls DataProtection in, and then you get warnings - in code your app doesn’t use.

[eerhardt]

A potential workable solution for the warnings:

1. Annotate System.Security.Cryptography.Xml as RequiresUnreferencedCode as in dotnet/runtime@main...eerhardt:runtime:AnnotateSSCXml.
2. We also add some more information to the exception messages that are thrown from System.Security.Cryptography.Xml regarding trimming. Ex. "If you are trimming your application, ensure the types being used are being preserved."
3. We figure out the list of commonly used crypto algorithms used by DataProtection, and add [DynamicDependency] attributes for them. We also add some trimming/aot tests to ensure the attributes are working.
4. DataProtection then suppresses the warnings coming from System.Security.Cryptography.Xml

This solution at least solves the warnings. It doesn't solve the size problem, but that is less important (but still important, since one of the main reasons you are trimming is so your app is smaller). The main thing blocking a user from using AddAuthenticationCore() themselves is that DefaultAuthenticationConfigurationProvider is internal. Of the things AddAuthentication() does:

aspnetcore/src/Security/Authentication/Core/src/AuthenticationServiceCollectionExtensions.cs

Lines 19 to 29 in 4190655

	public static AuthenticationBuilder AddAuthentication(this IServiceCollection services)
	{
	ArgumentNullException.ThrowIfNull(services);
	services.AddAuthenticationCore();
	services.AddDataProtection();
	services.AddWebEncoders();
	services.TryAddSingleton<ISystemClock, SystemClock>();
	services.TryAddSingleton<IAuthenticationConfigurationProvider, DefaultAuthenticationConfigurationProvider>();
	return new AuthenticationBuilder(services);

AddDataProtection() is the only thing that JWT Bearer auth doesn't need. It needs the other 4 things to be done. A user could manually do 3 of the things (AddAuthenticationCore, AddWebEncoders, Add SystemClock) but the last DefaultAuthenticationConfigurationProvider is internal.

We could make a new AddAuthentication method that doesn't AddDataProtection, but naming that method is going to be really hard - since AddAuthenticationCore is already used.

[Tratcher]

It seems like we need to take a step back and figure out exactly how much of this needs to work.

For our current goals for .NET 8, which is just JWT Bearer token authentication, none of it needs to work. The issue is that just calling AddAuthentication() pulls DataProtection in, and then you get warnings - in code your app doesn’t use.

Except we're encrypting the bearer tokens?

[DamianEdwards]

Except we're encrypting the bearer tokens?

He means the existing JWT auth handler, not the token support we're adding to Identity. The JWT auth handler doesn't use Data Protection.

[eerhardt]

Except we're encrypting the bearer tokens?

Can you show me where?

For .NET 8, my understanding is we only need to make this code work.

builder.Services.AddAuthentication()
    .AddJwtBearer();

That only needs to decrypt the tokens, and Microsoft.IdentityModel is doing that, as far as I know.

[halter73]

Correct. JWT bearer tokens are verified using IdentityModel rather than DataProtection and AddJwtBearer is not in the business of creating tokens, but the new opaque identity tokens created by #47414 use DataProtection just like cookies.

[jamiewinder]

I'm struggling to get a feel for where AddJwtBearer support is when using NativeAOT, especially with .NET 8 GA looming. Is there a workable solution for this now, or will one be available by GA?

[DamianEdwards]

@jamiewinder that support should land as part of an upcoming RC release.

[jamiewinder]

Sorry to pester, but can we still expect this prior to release? It feels like it'd be a big omission if we can't practically use JWT with NativeAOT web apps.

[DamianEdwards]

@eerhardt for confirmation of the status of JWT support for native AOT. My understanding is we're still on track to have this land for 8.0

[eerhardt]

With the release of .NET 8 RC2 yesterday (see https://devblogs.microsoft.com/dotnet/asp-net-core-updates-in-dotnet-8-rc-2/), JWT Bearer authentication is fully supported in Native AOT. Please update to use the 8.0 RC2 SDK and update your PackageReference to https://www.nuget.org/packages/Microsoft.AspNetCore.Authentication.JwtBearer/8.0.0-rc.2.23480.2. When publishing for NativeAOT you will no longer get warnings from inside the Microsoft.IdentityModel.* libraries.

Note that this issue isn't about AOT-compatibility, but instead about size reduction. JWT Bearer auth doesn't require DataProtection in order to work. But in order to add JWT Bearer auth to your app, you need to call builder.Services.AddAuthentication() which brings in DataProtection. This issue is tracking a way to remove the dependency on DataProtection when it isn't needed (like in the case of JWT Bearer auth).

[ghost]

We've moved this issue to the Backlog milestone. This means that it is not going to be worked on for the coming release. We will reassess the backlog following the current release and consider this item at that time. To learn more about our issue management process and to have better expectation regarding different types of issues you can read our Triage Process.