I have a solution that I was tasked to update from .NET Framework 4.6 to 4.8 (can't go any higher than that). We also need to add Okta as an auth method.
The solution has with multiple projects and it already uses an Identity Server bearer token authentication method, that needs to work in tandem with Okta. I have already done this using authorization filters in a previous solution that I also had to update/add Okta to.
But the problem I am having is that Okta's SDK, or more precisely, the dependencies it requires to work, are completely incompatible with Identity Server 3 and its dependencies.
Here are constraints of the Okta SDK (Package: Okta.AspMvc):
I have set up an Okta auth project and added this exact dependencies and versions. In the other projects of my solution, I have older versions of this packages. Some examples:
System.IdentityModel.Tokens.Jwt v4.0.4.4030
Microsoft.Owin.Security.Jwt v3.1.0
IdentityServer3.AccessTokenValidation v2.15.0
Microsoft.AspNet.Identity.Owin v2.2.1
The solution, then, seems simple enough: either downgrade Okta's SDK to a version that works with the older packages, or (the correct one) upgrade all of the other packages in your solution. However, this has proven not to be the case, as neither of this approaches seem to work. Here's what happened:
1. Downgrading Okta: even the oldest version of the SDK has the exact same package constraints as the ones in the picture I attached earlier. Any version of the package requires the same versions of its dependencies,so there's no downgrading Okta.
2. Upgrading everything else: the most intuitive solution, and yet the most baffling. Upgrading every single dependency to its latest, even matching the versions to those found in the Okta auth project, will still throw the following error:
Could not load type 'System.IdentityModel.Tokens.TokenValidationParameters'
from assembly 'System.IdentityModel.Tokens.Jwt, Version=6.17.0.0, Culture=neutral,
PublicKeyToken=31bf3856ad364e35'
This TokenValidationParameters class it's being used in my Authorization filter to check the correctness of the Okta token I am getting. Here's a sample of that code:
var validationParameters = new TokenValidationParameters
{
RequireExpirationTime = true,
RequireSignedTokens = true,
ValidateIssuer = true,
ValidIssuer = issuer,
ValidateAudience = false,
ValidateIssuerSigningKey = true,
IssuerSigningKeys = signingKeys,
ValidateLifetime = true,
ClockSkew = TimeSpan.FromMinutes(2)
};
Deleting this code of course does nothing, since the problem it's with a dependency inconsistency and not with the code itself. Deleting those lines will still produce the same error.
However, there should be no dependency inconsistency, since now all versions match.
I did find this Github issue opened in the AspNetKatana repository that seems to indicate that even if all packages in all of your projects are correctly updated, you may still get this error in your solution if you're using IdentityServer3.AccessTokenValidation, since it gets "stuck with an old dependency on Microsoft.Owin.Security.Jwt 3.0.1". I cannot prove that the commenters are correct, but it would make sense they are, given the situation I am in.
So even if I update my packages, IdentityServer3 will remain holding on to older versions.
Which would then take me to solution number 3:
3. Upgrading IdentityServer: I tried this as well. I am already using the latest version of IdentityServer3, so the only way would be to move over to IdentityServer4. This is also problematic, since IS4 introduces several breaking changes (for example, it does not work with IAppBuilder, which it's what my API projects use).
Even if possible, it would be very costly to move over to IdentityServer4.
Has anyone ever encountered this issue? Or anyone has any idea on how to fix it?
Related
We are using two libraries WireMock.Net & WireMock.Net.RestClient which are reporting vulnerabilities in our dependency checker (NVD). Both of those libs are version 1.5.9.
The following are listed as published vulnerabilities with most set at Medium some two or three are rated high & at least one is rated critical.
CVE-2018-8909,
CVE-2018-9116,
CVE-2018-9117,
CVE-2020-15258,
CVE-2020-27853,
CVE-2021-21301,
CVE-2021-32665,
CVE-2021-32666,
CVE-2021-32755,
CVE-2021-41093,
CVE-2022-23625,
CVE-2022-31009
I have already upgraded from an earlier version which only had one vulnerability (relating to wire IOS). Upgrading has pulled in the RestClient &, apparently, a new bunch of vulnerabilities. There is no further option to upgrade as WireMock.net 1.5.9 is the latest stable even though some of the vulnerabilities list versions before 2.16 as the problem. I suspect that is mixed up with Java or other versions of WireMock.
So,
Do I need to move away from from this library or are these
vulnerabilities false positive?
how do I move away from this library?
Which library would be best to replace this one?
RestClient
wiremock.net
Thanks for any help in advance.
I cannot use dependency checker (NVD), but when checking your links related to ossindex.sonatype.org : https://ossindex.sonatype.org/component/pkg:nuget/WireMock.Net I don't see any issues:
Also running
dotnet list package --vulnerable
Shows no issues:
PS C:\Dev\GitHub\WireMock.Net> dotnet list package --vulnerable
The following sources were used:
https://api.nuget.org/v3/index.json
C:\Program Files (x86)\Microsoft SDKs\NuGetPackages\
The given project `WireMock.Net` has no vulnerable packages given the current sources.
The given project `WireMock.Net.Abstractions` has no vulnerable packages given the current sources.
The given project `WireMock.Net.RestClient` has no vulnerable packages given the current sources.
The given project `WireMock.Net.StandAlone` has no vulnerable packages given the current sources.
These CVEs seem pretty serious, i would switch libraries.
Some alternatives include Moq and Xunit.
I am getting the following runtime exception, except I think my case is different than the dozen or so I've seen so far, most of which are a couple years old.
Could not load file or assembly 'System.ValueTuple, Version=4.0.3.0, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51' or one of its dependencies. The system cannot find the file specified.
We had been using System.ValueTuple and ran into these common issues back when they first incorporated the library into the core language. Since then we have removed all references to the old nuget package and all projects target 4.7.
Since then we have been successfully using the ValueTuple constructs throughout our solution without any problems. Until now, I have a specific call that fails, while other calls that return a ValueTuple succeed, from within the same method. I don't know what the difference could be since all the calls use custom objects serialized across a SignalR hub through an interface like:
Task<(MyObject myobj, Guid myguid)> GetStuffd(Guid id);
I bumped all our projects to 4.7.2. I removed every binding redirect in every app.config file. Still nothing. And since other ValueTuple calls work from the same project, I don't think I'm on the right track with these kinds of solutions. Any ideas?
The problem was actually server-side and removing the binding redirect from my host service easily solved the problem.
It's worth noting that a new .Net Standard 2.0 library was the catalyst here. My call down into a .Net Standard class library is what prompted the issue. This is what was different from other calls already using ValueTuple.
Clearing the binding redirects was indeed the solution after all.
I'm in dll hell.
I'm building a plugin for a huge, ancient and very powerful software suite called ANSYS. They have a plugin framework. I had hoped that they would magically handle everything for me via AssemblyContexts or AppDomains or some other clever dotnet device that I don't understand. They do not.
The result is that I've created an application that depends on GRPC.core 1.16.0 via nuget. I wrote a little application that drives my plugin with a winform host. It loads and works perfectly, finding my library in ~/myproject/bin/debug/grpc.core.1.1.16.dll that exists right beside the class-library that is my plugin, no problem.
When I run my plugin in the ANSYS process space, which happens to also depend on grpc 1.0.0.0, the linker finds C:\Program FIles\ANSYS\...\WIN64\grpc.core.dll. No Good.
One odd thing about the Nuget GRPC package is that it adds a reference with a "reference version" of 1.0.0.0, where most other nuget packages have their reference version match the nuget package version. If i manually change the reference version the compiler wont find the library.
<Reference Include="Grpc.Core, Version=1.0.0.0, Culture=neutral, PublicKeyToken=d754f35622e28bad">
<HintPath>..\packages\Grpc.Core.1.16.1\lib\net45\Grpc.Core.dll</HintPath>
</Reference>
edit: the key is in the above line. The Nuget published Grpc.core artifact is at AssemblyInformationVersion=1.16.1.0, AssemblyFileVersion=1.16.1.0, AssemblyVersion=1.0.0.0. I logged this as a request against GRPC. More Below.
Thus I need to tell the runtime linking facilities not to use grpc.core...dll found in ANSYS's own binary directoryWhats more, there is exactly one dll (and its dependents) that I wish to load from my parent processes context: and that's ANSYS API dlls themselves, which are probably already in the GAC. In my project I've included this as a non-nuget reference with "build action: do not copy" selected.
So my questions:
is there something simple and easy I can do at runtime to tell the runtime-linker "when somebody loads a type from an assembly you think should be grpc.core, do not load 1.0.0.0, find 1.16.0.0 exactly"?
the runtime was already matching the needed library by "strong
name". The problem is that the 1.16.0 is a misnomer. That version
string was informational, but the assembly itself was version
1.0.0.0. Fusion was loading the library I wanted by exact match already.
is there something smarter I can do with appdomains or contexts or another C# device to explictly enter some kind of nested scope? Could I go so far as to log this as a bug in ANSYS's API?
I've tried digging into this myself, but I'm not a dotnet expert and finding out whether I'm looking at a nuget package configuration option --which isn't relevant to me, or an old-fashioned dotnet runtime option, has been very tricky.
update 1:
I've tried using AppDomain.CreateDomain, and it does indeed solve my problem, but it also requires me to provide a marshalling strategy for the already-loaded API objects. In other words, if you're programming against a plugin framework that has an api similar to:
public void DoMyPluginsFunctionality(ApiProvidedInputContext context){
var myPlugin = AppDomain.Create(
strongName: "MyCompany.MyPlugin.; Version=1.2.3.4 ...",
baseDirectory: "C:\\Program Files\\MyPlugin\\bin"
)
//success! MyCompany.MyPlugin loads the version of GRPC I want!
myPlugin.unWrapAsDynamicProxy().doFunctionality(context)
//error: No marshalling strategy and/or not serializable and/or swizzling errors
}
Then the runtime will require you to marshall (serialize) the context variable, because .net will not let you share memory across AppDomain boundaries.
So my new question:
- given I cant use AppDomains myself
- given that Grpc.core is always published as AssemblyVersion=1.0.0.0
What are my options?
Stop using newer features of GRPC.core and live in fear of my parent processes dependencies
use a strategy similar to shading. Is there something like shading in the .net world?
Edit the published binary's version metadata. Can I dynamically edit a published binaries version?
rebuild GRPC myself with the version string updated --effectively a private fork of GRPC.
update 2:
The GRPC build system seems like its quite large and well maintained, so I'm hoping I can simply build it and change a vcproj file to include an updated version string.
Unfortunately it also seems quite complex, and I haven't quite got the targeting/cross-compiling (x64 targeting x86) worked out.
I have created an applicataion in c#, where I need to put some data on S3 bucket, and to Invoke AWS sagemaker APIs.
Since the same Amazon.RegionEndPoint class exists in both the references, it is giving below error.
The type 'RegionEndpoint' exists in both 'AWSSDK.Core,
Version=3.3.0.0, Culture=neutral, PublicKeyToken=885c28607f98e604' and
'AWSSDK, Version=2.3.55.2
Basically I am trying to upload files on AWS S3, following code I have used.
AmazonS3Client s3Client = new AmazonS3Client(_AWS_ACCESS_KEY_ID, _AWS_SECRETE_ACCESS_KEY, Amazon.RegionEndpoint.USEast2);
PutObjectRequest request = new PutObjectRequest
{
BucketName = _BucketName,
Key = i_sDestFileName,
FilePath = i_sSourceFilePath,
ContentType = "text/plain"
};
s3Client.PutObject(request);
It is working fine on a single application, but when I integrated code with Sagemaker API invokation, the conflict occurs for Amazon.RegionEndpoint.USEast2.
Don't use AWSSDK package along with AWSSDK.Core. Remove it using the package manager and add your service-specific packages, for example, AWSSDK.S3 or AWSSDK.EC2 .
AWSSDK.Core is a new one with .NET core support and with that you need to install service-specific packages, while the older AWSSDK is a single package for all services. Below is the description of the older AWSSDK package from nuget:
This is the previous version 2 generation of the AWS SDK for .NET. The new version 3 of the AWS SDK for .NET uses separate packages for each service. For example Amazon S3 is in the AWSSDK.S3 package, Amazon SQS is in AWSSDK.SQS and Amazon DynamnoDB is in AWSSDK.DynamoDBv2.
Once you remove the older one and use the specific packages, the conflict will be resolved. But, note that there may be other errors then, as the constructs have changed slightly but are obvious/simple to fix. On the positive side, you get the async versions. ;)
--
// Noticed a comment from #Gerry-coll, above, on the main question, also mentions this. Leaving a detailed answer for others who bump into this issue even now.
It looks like you have two different versions of the AWS SDK installed, one much older than the other. I'd look to SO questions like Where does error CS0433 "Type 'X' already exists in both A.dll and B.dll " come from? for advice on resolving the conflict.
Consider moving your region details to of config file and access it from there. https://docs.aws.amazon.com/sdk-for-net/v3/developer-guide/net-dg-region-selection.html
I have installed SwaggerUI for .Net from Nuget package and trying to test web api methods with the swagger. But I am get below compile time error.
Error Assembly generation failed -- Referenced assembly 'WebActivator' does not have a strong name
When I change the solution settings for signing property from checked to unchecked I don't get this error. Now I don't want to change any settings that are made to signing property of solution settings and fix this error.Can any one please help me to fix this error?
Your assemblies are strong named while the new assemblies you referenced recently are not. And more than this, they are not compiled from source (you got them via NuGet).
Two workarounds cross my mind now:
Get the sources for SwaggerUI and dependecies and sign them with your key. I think this is a tedious process, since you need to build everything.
Use the DLLs like now and sign them after each build. For example you can use these instructions (dissasemble, sign & re-assemble). If you do this, I think it's worth adding this as a pre-build step to your least-dependent project (the one that builds first).
I have also found this - Assembly Strong Naming Toolkit (for NuGet). Never tried, but maybe it's worth looking into as it seems to be designed for your case.