I'm using the sample provider and relying party applications that come in the DotNetOpenAuth v4.0.0.12084 zip download and getting a protocol exception within the provider.
The web.config files provided in the samples don't appear to be valid as they try to use ASP.NET MVC 3 with .NET framework 3.5 (2). So I've updated them to use .NET framework 4.
These test URLs are unfortunately on my desktop and not available over the internet.
The provider is running on:
http://login.puffin.mediaburst.co.uk/
Relying party on:
http://testlogin.puffin.mediaburst.co.uk/
OpenID url used when logging in to the relying party:
http://login.puffin.mediaburst.co.uk/user/bob
I get the following error when submitting the OpenId using the relying party:
Error while reading message 'DotNetOpenAuth.OpenId.Messages.CheckIdRequest'
parameter 'openid.claimed_id' with value
'http://login.puffin.mediaburst.co.uk/user/bob'.
Invalid cast from 'System.String' to 'DotNetOpenAuth.OpenId.Identifier'.
(Contact: , Reference: )
I've enabled log4net and have put the provider logfile on pastebin
To test the relying party I've authenticated against google and it works fine, suggesting the request format is correct.
Does anybody have any suggestions on stopping this invalid cast exception?
Yours is the second report for this bug. I've filed issue #109 to track this.
Incidentally, I believe the samples are correct, since MVC 3 works fine on .NET 3.5, as far as I can tell. Although a known bug was that if MVC 4 is also installed on your machine that you build the samples on, they incorrectly bind to MVC 4 DLLs and result in a runtime failure.
Related
I´m currently evaluating Web Dav Product for .NET and I´m really impressed. I only noticed that when I´m integrating the sample code (Asp.NetFileSystem) into my existing ASP.NET Web API 2 Project, it doesn´t work with Office Word directly as a save target.
We have Web API 2 with Windows Authentication and CORS Headers on.
Windows Explorer can open and Navigate the WebDAV Folder and I can create new files there. But when I´m saving from word directly, I get errors in Word that the network path does not work / exist. I tried to debug it but it happens
I separated the WebDAV part in it´s own project for test purposes and it works without the problems.
Am I using it wrong in the context of Web API 2, or is this an unsupported usecase?
I´ll try to get fiddler logs to.
Thanks a lot!
Thanks to the IT Hit WebDav we were able to trace the problem down. To work correctly, OPTION requests have to be processed by the WebDAVHandler. We have a custom module which intercepts OPTION requests to handle CORS. Because of our Module, the WebDAVHandler was not able to add the necessary headers, and Office opened the files readonly.
I built a claims-aware asp.net mvc application following the steps outlined in this page: https://learn.microsoft.com/en-us/dotnet/framework/security/how-to-build-claims-aware-aspnet-mvc-web-app-using-wif. The example in the page uses an STS on the local host, but in my application I am pointing to a fully-functioning AD FS on a different server.
I'm using Framework 4.7 and Windows Server 2016 to host the AD FS and to host the web application.
After I deployed the application I ran the Windows Identity Federation Utility against it (because I thought I needed it to add the application as a Relying Party Trust on the AD FS). This utility inserts a lot of tags into the web.config that refer to the Microsoft.IdentityModel namespace.
I then added the application as a Relying Party Trust to the AD FS, and navigated to the claims-aware app. The page failed because the sample code cast the claim returned by the STS as System.Security.Claims.Claim. When I changed it to cast as Microsoft.IdentityModel.Claims.Claim it worked fine.
The example I was following makes no mention of the Windows Identity Federation Utility. Do I need to use that? Or would this have worked without it?
When I try reversing the web.config changes that the utility inserted the site fails with a 401 error (access denied due to invalid credentials) so obviously the stuff inserted by the Utility is needed to get authentication from AD FS. Is this because I ran the Utility on the web site before adding it as a relying party trust to the ADFS?
The answer here is: don't run the Windows Identity Federation Utility if you are using ADFS Server 2016, as it forces use of the Microsoft.Identity libraries, which are deprecated. I mistakenly thought this utility was needed to create the FederationMetadata.xml file.
I created the FederationMetadata.xml file manually and reverted my web.config back to what it was before I ran the utility. This reverted me back to using the System.Identity libraries, which were added to the 4.5 framework, instead of the now-deprecated Microsoft.Identity libraries.
Just to note that the more "modern way" is to use the OWIN WS-Federation library.
This example is for Azure AD but you simply point to the metadata and the code figures all the rest out for itself.
I wanted to implement a small Proof of Concept for ADFS integration with MVC application. For this I created a virtual machine for Windows 2008 R2 and configured ADDS, ADCS and added my updated my server domain to one created one using ADDS.
After this I created certificate using ADCS.
Now, installed ADFS 2.0 using Microsoft download of ADFSSetup.exe RTW.
With help of some I configured ADFS & added relying party trust from my MVC application SSL URI.
After this I tried to run the application however started facing 403.14 error page.
Following observations as outcome from entire configuration:
I tried to access "<>/federationmetadata/2007-06/federationmetadata.xml" and I
got a proper XML which is as per expected.
I saw couple of entries from server computer - IIS website as like "http://<>/adfs/services/trust" OR "https://<>/adfs/ls/" however couldn't get any response from server. even I tried to access same from server using localhost instead of server names, then also no luck.
Then to cross-verify I checked IIS's default website where I found adfs/ls however it was a like a website. Not sure correct or not. I couldn't find anything 'services/trust' under ADFS IIS application.
After that I installed ADFS from Server manager and saw one more virtual directory 'fs',added under adfs application. when I tried to access 'fs' using https I am able to access it easily and can see SOAP service and page displayed with available web method.
I tried to find more on 'adfs/ls' and 'adfs/services/trust' however couldn't get much more information.
Please, if anyone came across this issue. Do let me know.
This is not an issue, this is how ADFS works. Next step you have to configure claims providers and relying parties from ADFS management console (from Admin tools). Relying party could be a sample claims aware MVC application. It should work
The only URL's that ADFS "answers" to are the federation metadata endpoint and the IDPInitiated one.
adfs/ls expects either WS-Federation or SAML parameters after it. On its own it will throw an error.
Then follow How To: Build Claims-Aware ASP.NET MVC Web Application Using WIF.
Why are you using Windows 2008 R2? (ADFS 2.0)? You should rather use Windows 2012 R2 (ADFS 3.0).
I am upgrading my 2.40 version developed in mvc3 to mvc5, I updated all required references. I also upgraded autofac reference to version 3.0.0.0. It built successfully but throwing below exception on running application.
No scope with a Tag matching 'AutofacWebRequest' is visible from the scope in which the instance was requested. This generally indicates that a component registered as per-HTTP request is being requested by a SingleInstance() component (or a similar scenario.) Under the web integration always request dependencies from the DependencyResolver.Current or ILifetimeScopeProvider.RequestLifetime, never from the container itself.
Checked different posts also tried to use
builder.RegisterType().As().SingleInstance();
but no success.
Any solutions.
I am currently using DotNetOpenAuth v4.1.0.12182 to perform simple Relying Party functionality and was able to get it working (tested Google and Yahoo) without even adding any web.config entries. However, this site will be deployed onto web servers which have the following setting enabled:
Go to Control Panel > Administrative Tools > Local Security Policy
Find the setting "System cryptography: Use FIPS compliant algorithms..." and set it to Enabled
Without this enabled the site works fine. With this enabled I get the Server Error "This implementation is not part of the Windows Platform FIPS validated cryptographic algorithms". I did find information on the dotnetopenauth v4-0 beta release page which mentions that, as of the DotNetOpenAuth 4.0 release, one of the changes was "FIPS-compliant SHA algorithms can now be configured in your .config files."
What I need help with...
I am seeking to know what config changes I need to make in order to get this FIPS message/error to go away. I've looked at [http://www.dotnetopenauth.net/developers/help/configuration-options/][2] but cannot find any clarity on it as to what is FIPS related. Any help would be greatly appreciated, thank you!
Updated (7/10/2012)
I'm providing the steps I've re-taken so the error can be replicated:
I used a fairly fresh install of Server 2008 R2 Enterprise (already had VS 2010 installed and perhaps some updates)
Added the Web Server Role
Added the .NET Framework 3.5.1 Feature
Enabled the Local Security Policy: System cryptography: Use FIPS compliant algorithms for encryption, hashing, and signing
Restarted the server
Compiled/built the OpenIdRelyingPartyWebForms sample and published it for use as a local IIS website
Ran into a URI error that caused me to have to set the App Pool to use ASP.NET v4.0
Ran into another error that caused me to have to "force install of .NET 4": http://devonenote.com/2010/06/could-not-load-type-system-servicemodel-activation-httpmodule/
Now the "Relying Party" webpage finally rendered so I clicked the Members Only link and then clicked the Sign In with a Yahoo ID option
After about a 2-3 second pause for it processing I receive:
[InvalidOperationException: This implementation is not part of the Windows Platform FIPS validated cryptographic algorithms.]
System.Security.Cryptography.SHA512Managed..ctor() +4479214
[TargetInvocationException: Exception has been thrown by the target of an invocation.] when trying to do System.Security.Cryptography.SHA512.Create +11 and then System.Security.Cryptography.CryptoConfig.CreateFromName +1195
[TypeInitializationException: The type initializer for 'DotNetOpenAuth.OpenId.HmacShaAssociation' threw an exception.] DotNetOpenAuth.OpenId.HmacShaAssociation.TryFindBestAssociation (cs:134)
Troubleshooting steps...
Added the config entries (based upon the link that Andrew provided) to the Framework64/v4.0.30319/Config/machine.config under the tag. However, since I have not yet added the Security.Cryptogrophy DLL anywhere I removed those lines from the config (the ones dealing with HMACSHA512).
Restarted the machine
Browsed back to and clicked the Sign In with a Yahoo ID button
[InvalidOperationException: This implementation is not part of the Windows Platform FIPS validated cryptographic algorithms.]
System.Security.Cryptography.SHA384Managed..ctor() +4486510
[TargetInvocationException: Exception has been thrown by the target of an invocation.] when trying to do System.Security.Cryptography.SHA384.Create +11 and then System.Security.Cryptography.CryptoConfig.CreateFromName +1195
[TypeInitializationException: The type initializer for 'DotNetOpenAuth.OpenId.HmacShaAssociation' threw an exception.] DotNetOpenAuth.OpenId.HmacShaAssociation.TryFindBestAssociation (cs:134)
What I noticed is that now it is complaining about SHA384 instead of SHA512, so the machine.config entry for SHA512 (telling ASP.NET to use the SHA512Cng class within System.Core) must be working!
So next I proceeded to add SHA384 & SHA256 entries, did an iisreset, and browsed back to and clicked the Sign In with a Yahoo ID button. This time I was finally redirected to Yahoo, logged in, and was sent back to my localhost URL but received this FIPS error:
[InvalidOperationException: This implementation is not part of the Windows Platform FIPS validated cryptographic algorithms.]
System.Security.Cryptography.HMACSHA256..ctor(Byte[] key) +4491026
So now I proceeded with the following:
Added in the HMACSHA512 machine.config line I originally took out and duplicated it for HMACSHA256
Added the Security.Cryptography.dll file from the codeplex project referenced in Andrew's response to the GAC (windows\assembly) as per this MSDN blog
Restarted the machine
Browsed to and clicked the Yahoo button again but received the same error
It appears as if the new Cryptography DLL was not being "picked up" by ASP.NET and used. So, next I tried:
Removing the DLL from the GAC
Restarting the machine
Added the Cryptography DLL as a reference to the OpenIdRelyingPartyWebForms sample and re-compiled and published it, overriding the exisiting IIS website files
Browsed to and clicked the Yahoo button again but received the same error
Any ideas on how I can get past this problem with HMACSHA256?
You need to configure .NET itself to create the FIPS-compliant versions of the required algorithms. Please check out this previously filed and fixed issue, including the comments, for guidance on how to proceed.
Using Andrew's comment/link I was able to get the solution working. However, I was never able to overcome the FIPS issue using .NET Framework 3.5. I had to upgrade to .NET Framework 4.0 and then add the following to the root configuration element of the machine.config XML file:
<mscorlib>
<cryptographySettings>
<cryptoNameMapping>
<cryptoClasses>
<cryptoClass CoreSHA512="System.Security.Cryptography.SHA512Cng, System.Core, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089"/>
<cryptoClass CoreSHA384="System.Security.Cryptography.SHA384Cng, System.Core, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089"/>
<cryptoClass CoreSHA256="System.Security.Cryptography.SHA256Cng, System.Core, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089"/>
</cryptoClasses>
<nameEntry name="System.Security.Cryptography.SHA512" class="CoreSHA512"/>
<nameEntry name="System.Security.Cryptography.SHA384" class="CoreSHA384"/>
<nameEntry name="System.Security.Cryptography.SHA256" class="CoreSHA256"/>
</cryptoNameMapping>
</cryptographySettings>
</mscorlib>
In case the XML was stripped out above, follow the link that Andrew provided and you'll find the XML in the post by joeudwin. I removed the lines for "TestHMACSHA512" and duplicated the lines for "TestSHA512" for 384 and 256 entries. I did not need to download Security.Cryptography.dll from CodePlex.