This is a second attempt with better wording of the problem I'm facing.
I have a simple requirement to implement an application that will allow web applications and standalone services that will be claims-aware (using ADFS). Note that I am talking about windows services in addition to web applications.
Which enabling interoperable technologies should a developer pick?
For the life of me, I can't find a resource that says: to build a claims-aware application using the latest upcoming frameworks, install these packages.
From a framework point of view, I am talking about the following:
Microsoft.IdentityModel
Microsoft.Owin
System.IdentityModel
Microsoft.Asp.Net.Identity
Which should I be using? Alpha / Beta packages are fine.
Thank you,
Richard
in .net 4.5 IdentityModel is now part of the core libraries (so it no longer called Microsoft.IdentityModel).
So for your system you would need the following:
System.IdentityModel for the FederationAuthenticationModule (which intercepts and verifies your SAML token submission) and for the SessionAuthenticationModule (which serializes/deserializes your claims.)
To create the claims that you will send between your applciations you would use:
System.Security.Claims
as I mentioned these are both in .net 4.5.
Microsoft.IdentityModel is the one you are looking for.
Microsoft.IdentityModel.Claims for IClaimsIdentity interface.
Microsoft.IdentityModel.Web for WSFederationAuthenticationModule.
Yup - System.IdentityModel is the way to go.
Refer: What's New in Windows Identity Foundation 4.5.
If you are wondering what the difference between WIF 3.5 and 4.5 is, refer:
Guidelines for Migrating an Application Built Using WIF 3.5 to WIF 4.5
Related
I’m looking for a package to support SAML protocol on my IDP built in .Net 4.5 standard. I need to return SAML responses to the SP, either SP initiated or IDP initiated.
Do you have a solution for this without upgrading to .Net core with Windows Identity Foundation (WIF) support ?
You can use componentSpace saml library.
We are using both. Net 4.5 and . Net core libraries and it is a great solution.
https://www.componentspace.com/saml-for-asp-net?gclid=CjwKCAjw_o-HBhAsEiwANqYhp7BkOttS4Vve4QHJz-PS6taO89AV6gflhB6FgUZMmuZ1qNq65wgsDhoCf4wQAvD_BwE
If you are not willing to purchase any tool, you can write code by yourself as well. If you follow the saml standards carefully, it will be easy to code.
I would strongly advise you not to write the code yourself!
There is a list of SAML client-side stacks here.
I'm confused about the reference to WIF though because WIF is WS-Federation not SAML.
I'm afraid that the ITfoxtec Identity SAML 2.0 package do not support neither .NET Framework 4.5 or WIF.
You need to upgrade to at least .NET Framework 4.6.1.
I'm making an HTTPS call over TLS 1.2 with client certificates to another company using .Net Framework 4.8 and the handshake fails after the client certificate is sent. Their company support claims .Net framework does not support SNI using this page as reference https://www.ssls.com/knowledgebase/what-is-sni-technology/. However my network capture indicates it does, since it includes the "server_name" extension in the client hello..Net framework call with SNI extension The same call can be made successfully using python so there is evidence they are correct, but I can't find any definitive answer online regarding .Net Framework. How can we determine if the issue is their network or lack of support in our framework?
Edit: This website indicates there is support since 4.5 https://developer.awhere.com/api/server-name-indication-sni-support-requirements
.NET Framework don't care about SNI support, because .NET has no knowledge of it. Network operations in .NET Framewrok are built around a network stack and low-level API provided by operating system. If you were able to install .NET 4.8, then you are running your app on a modern client that certainly supports SNI. This means that the issue is elsewhere, but not in .NET Framework.
I can't find any definitive answer online regarding .Net Framework
and you won't find for reasons explained above.
The simple answer is no, it does NOT, not in NetStandard 2.0 either.
But it does with netcore-5+.
Prior to that, while it supported client connections, it did not support customized selecting of the TLS-certificate based on SNI prior to netcore-5.
You could do it prior to that with the StreamsExtended library, though.
However, that's not part of the official .NET Framework, but a 3rd party library.
So no, the full .NET framework does not support that at all.
I am migrating an ASP.NET application to be on ASP.NET Core, but have met a problem of Ws-Federation authentication: there is no [Ws-Federation] (https://www.nuget.org/packages?q=Microsoft.Owin.Security.WsFederation) OWIN middleware available in ASP.NET Core platform.
But I noticed all authentication middleware for ASP.NET Core are now under Microsoft.AspNetCore.Authentication namespace, so I searched all packages from nuget.org and found most of the authentication packages are there, but unfortunately only the Microsoft.AspNetCore.Authentication.WsFederation is missing.
So, I would like to know, if the package is missing because it is not implemented yet or any other reason? Alternatively, is there existing ASP.NET Core based authentication middleware for Ws-Federation?
It's not implemented yet, mainly because .NET Core doesn't have the encrypted XML and XML dsig classes needed.
See https://github.com/AzureAD/azure-activedirectory-identitymodel-extensions-for-dotnet/issues/500
I've ported the Katana middleware over to ASP.NET Core. It has a hard dependency on the full .NET Framework since that is the only place the required libraries exist right now.
https://github.com/chrisdrobison/aspnetcore-wsfed
It appears .NET Core 2.1 WS Federation package is now available. Microsoft.AspNetCore.Authentication.WsFederation.
More information found at the following link:
https://learn.microsoft.com/en-us/aspnet/core/security/authentication/ws-federation?view=aspnetcore-2.1
My application is ASP.NET MVC5.1 and ASP.NET WEB API 2.1. The application
is small and currently using Microsoft Unity for IOC.
Can someone advise me if they know of any changes needed to make Unity
work with these very new releases of MVC and Web API?
I am also considering changing to Ninject depending on features.
If I made this move then what features does it offer that the latest version of Unity lacks? My big concern is that Ninject appears to be well supported whereas Unity seems to be a product that's updated every couple of years when the Microsoft guys have the time to look at it.
Finally how much of a change is needed if I change from Unity to Ninject?
I don't know much about Ninject, but we upgraded our MVC4 to MVC5 application here earlier this week, following the instructions for How to Upgrade an ASP.NET MVC 4 and Web API Project to ASP.NET MVC 5 and Web API 2.
The application is already in production, so I can confirm that Unity supports these new releases! Then you can continue to use it without any damage.
Hope it helps to make your decision.
See ya!
Yes, you can use Unity 3.0.1304.1 in ASP.NET MVC/WEB API 5.1 and 2.1 project.
I use it, because i can't configure ninject without any bugs for latest mvc core libraries.
I know we are really behind the times here, but we are just about to upgrade from .NET 1.1 to .NET 2.0.
Thank you for your sympathy.
Anyhow, are there any gotchas we should look out for?
Do you have any general advice before we jump in?
Please do not post telling me to go straight to 3.5: 2.0 is all we're allowed!
We're using mostly C#.
Yes. The most important thing for you to know is to use a Web Application Project, not a Web Site. Web Sites use a totally different compilation model and migration is pretty much a disaster. Web Application Projects are much more similar to how things worked in 1.1.
We also had an intermittent problem with redirecting from the login screen, but according to Google, we were basically the only ones who had that problem - we've since resolved it.
Most of the other problems we ran into were small and easy to navigate, and the overall experience was a net improvement.
Here is my recommendation before upgrading:
If you are used to use Visual Studio 2003, you will need to go for VS2005. You will have to convert the old solutions and projects so that it will be compatible with VS2005. Make sure to have a backup of the project you're going to convert so that you can roll back or even use it as source for any modification you may need to the converted projects.
If you're developing web applications using .NET 1.1, make sure that all the virtual directories and applications in the IIS is configured to work with ASP.NET 2.0. You may need also to configure a new Application Pool for your .NET 2.0 applications.
If you're using any third party libraries in your .NET 1.1 projects, you may need to confirm its compatibility with .NET 2.0 projects. Some old libraries used in .NET 1.1 are not compatible with 2.0.
One gotcha is home-grown 1.1 implementations of .NET 2.0 stuff (that was missing in 1.1) like RegistryHandler and so forth. Sometimes your newly-ported 2.0 code will look like it's properly using a 2.0 class when it's really using the home-grown version.
Deployment is another gotcha, if you're upgrading an already-deployed app. You have to switch the .NET version in IIS from 1.1 to 2.0.
I remember we had to change some client scripts, because the way ClientIDs are generated for server controls changed from ASP.NET 1.1 to 2.0.
I don't remember the exact circumstances, but some IDs which previously wer prefixed ctl0_ became ctl00_...