search

IdentityServer / IdentityServer3.AccessTokenValidation

OWIN Middleware to validate access tokens from IdentityServer3
Apache License 2.0
91 stars 149 forks source link

Assembly Signing and IdentityModel 1.0.0.0 vs 2.0.0.0 #129

Closed brianwagg closed 7 years ago

brianwagg commented 7 years ago

We are required to sign our assemblies which means every assembly we rely on needs to be signed (both strong name and digital/authenticode signed). I saw in a separate issue that you choose not to sign your assemblies, and we have to sign them ourselves. So I signed the IdentityServer3.AccessTokenValidation assembly but the fact that it relies on version 1.0.0.0 of IdentityModel is causing some issues because we are consuming the 2.0.0.0 version in our system.

Is there a reason it is not consuming 2.0.0.0? I tried putting the assembly binding statement in the web.config, but it seems that because the manifest is built against the 1.0.0.0 version of IdentityModel, that's what it wants.

What is the suggested mechanism for consuming these products when you have a requirement to both strong name sign and Digital/Authenticode sign your software that is consuming it? Is the only solution to download the source for everything in the chain and build and sign it ourselves? Am I missing something? Thanks for any insight.

leastprivilege commented 7 years ago

v1 and v2 of identitymodel are not compatible.

If we switch to v2 - others that have a dependency on v1 will have the same issue.

That's why we decided to stay on v1 for all Katana based stuff - and v2 for asp.net core.

brianwagg commented 7 years ago

So I put the version I'm using back to the 1.13 for IdentityModel so I'm using a V1 version of it. The issue I'm having is that I am trying to sign (strong name and authenticode) both the IdentityServer3.AccessTokenValidation.dll and the IdentityModel.dll. But because I'm strong name signing it and the reference in the AccessTokenValidation project doesn't specify a public key, it doesn't seem as though I can actually make any of it work.

I keep getting an error saying a strong name is required, even though the dll I have in the bin is now strong named and digitally signed.

Short of downloading your source and modifying it for my needs, do you know of a way (or has anyone else already handled this)? Maybe I'm missing something, but it seems like because the project requires the 1.0.0.0 and was built against that (without a public key token), nothing I do will allow me to use any of it with my signed software.

Thanks

brianwagg commented 7 years ago

I should clarify that we are using MEF at application start time to find specific exports, and that is what is walking the dependency tree to ensure it has the correct assemblies. Because the project in the AccessTokenValidation has publicKeyToken=null and now it is signed - it won't work.

Error: Broken assembly tree detected. Ensure there are no missing or mismatched assemblies. Could not load file or assembly 'IdentityModel, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null' or one of its dependencies. A strongly-named assembly is required.

leastprivilege commented 7 years ago

Sorry I don't know.

Strong naming is more trouble than it is worth it.