Windows Identity Foundation (WIF) is around for a while, may be 5 to 7 years or more!, now Microsoft made WIF part of .net framework (4.5) itself. As we know WIF is a middleware for building identity aware applications.
As the trend on the web technology is changing, we have now need to incorporate multiple other identity providers (Google, Facebook etc.), in our application.
Now the industry got other Middleware technologies like OWIN, ASP.NET Identity etc.,
My Question,
Is still the WIF relevant and do we need to consider using it for new projects?
Or
Do we need to implement OWIN as alternative middleware? (As I understand Microsoft is betting on OWIN / KATANA moving forward).
Please share your thoughts.
For new projects I highly recommend considering Katana and ASP.NET 5 OWIN middleware.
WIF remains supported as part of the .NET framework, however we stopped adding new features long ago - all the innovation has been poured in Katana and OWIN middleware in general. Also, we like to think that the OWIN middleware is significantly easier to use :) Again, if your project has legacy aspects that impose the use of WIF, you can go ahead knowing we'll support you: but if you have any chance of choosing, the OWIN middleware is the best path moving forward.
Totally agree with #vibronet but to answer the question - yes - still relevant.
There's a ton of WIF out there - I support lots of customers who still use it.
OWIN is easier to use but the nice thing about WIF is that everything is in the web.config so the details are more explicit and easier to change. However, that comes at the cost of a fairly steep learning curve.
Refer: OWIN : Differences with WIF and WIF : Wrappers around protocols.
As per the links:
"You can think of OWIN as MVC and WIF as Forms. Forms are still supported but all the new whizzy features and all the code samples relate to MVC.
It's important to note the neither OWIN nor WIF are protocols - they are the wrappers around the protocols. The protocols underneath both are identical."
Also consider we have moved some of the functionality of WIF into an open source project we refer to as Wilson. You can check it out here: https://github.com/AzureAD/azure-activedirectory-identitymodel-extensions-for-dotnet
Related
We are trying to implement single sign on, across multiple domains from MVC 4 application to .Net Core application.
MVC 4 to MVC 4 it's working fine with MachinKey, but not with .Net core.
How can we implement SSO to share the same authentication with all other application in MVC4 and .Net core application.
Identity Server can do this. Identity Server version 4 will be supported and free for as long as .NET Core 3.1 is supported. After that, you'll need Duende Identity Server, which is the next version, available on a commercial licence.
You can also do it with OpenID Connect (AKA OpenIddict) which is free for the foreseeable future, but that will probably need you to write a bit more code.
I have used both.
Both of them are agnostic to the type of client applications, so your clients can be MVC4, .NET Core, Xamarin, React, anything at all. Both of them have good templates that you can download and get started quite quickly with a simple scenario.
Unfortunately, in my experience, making meaningful extensions or changes to the templates (such as what you're proposing) was difficult and required in-depth knowledge of internet security concepts, studying the documentation and source code of whichever library that you choose.
I have tried really hard to learn but I still find it difficult, so I wish you good luck!
Here are the sample projects for IdentityServer4:
https://github.com/IdentityServer/IdentityServer4.Templates
And here is the documentation on how to get started:
http://docs.identityserver.io/en/latest/
Here are the sample projects for Open Id Connect:
https://github.com/openiddict/openiddict-samples
And here is the documentation:
https://openid.net/connect/
I've searched over Internet and I couldn't find any good resources explaining how to authenticate an ASP.NET Core web application through ADFS using the SAML protocol.
However, I found an old blog post saying that it was not supported and that it would not be until at least .NET Core 2.1. Except of that, I didn't find anything else.
However, I can't believe that something so important is not yet supported...
Does anyone has any experience with that? Note that Azure is not an option here.
Yes you can - see this example using Sustainsys.
You can also use ComponentSpace (examples in that blog) or Rock Solid Knowledge as per this example.
In an attempt to understand what I may use for OpenId Connect Server implementation, I have looked into what each of them is:
IdentityServer4:
an OpenID Connect and OAuth 2.0 framework for ASP.NET Core 2.
AspNet.Security.OpenIdConnect.Server:
is an advanced OAuth2/OpenID Connect server framework for both ASP.NET Core 1.x/2.x and OWIN/Katana 3.x/4.x, designed to offer a low-level, protocol-first approach.
OpenIddict:
OpenIddict aims at providing a simple and easy-to-use solution to implement an OpenID Connect server in any ASP.NET Core 1.x or 2.x application.
OpenIddict is based on AspNet.Security.OpenIdConnect.Server to control the OpenID Connect authentication flow and can be used with any membership stack, including ASP.NET Core Identity.
Also have checked that all of them use well the ASP.NET Core Identity as a membership system.
And so my current understanding is that IdentityServer4 and OpenIdConnect.Server are two alternative frameworks that solve the same problem. The main difference is the list of supported ASP.NET Core versions.
Regarding Openiddict - it is a kind of extension to simplify server creation based on AspNet.Security.OpenIdConnect.Server.
Have I missed something, or this is how things in general are?
EDIT (01/28/2021): as part of the 3.0 update, AspNet.Security.OpenIdConnect.Server and OpenIddict were merged to form a single/unified codebase under the OpenIddict umbrella, which should offer the best of both worlds: you still have the same experience as before, but can now opt in for the degraded mode, giving advanced users the same lower-level approach as AspNet.Security.OpenIdConnect.Server.
And so my current understanding is that IdentityServer4 and OpenIdConnect.Server are two alternative frameworks that solve the same problem. The main difference is the list of supported ASP.NET Core versions.
Actually, I believe the most important difference is that these two libs don't share the same objective. ASOS' only mission is to help you deal with the raw OAuth 2.0/OIDC protocol details: everything else is totally out of scope. Concretely, this means that concepts like users, applications or stores - that you can find in OpenIddict and IdentityServer - are completely inexistant in ASOS (which means you're free to bring your own implementation... and your own abstraction).
While IdentityServer will expose many abstractions and services allowing to configure specific features, ASOS - that was forked from Katana's OAuthAuthorizationServerMiddleware - has a centralized low-level events-based API (named OpenIdConnectServerProvider) that behaves exactly the same way as the ASP.NET Core security middleware developed by MSFT.
When working with ASOS, you have to deal with raw OpenID Connect requests and implement potentially sensitive things like client authentication (e.g using a database containing the client credentials) and that's why ASOS' core target is people who understand how the OAuth2/OIDC protocol work. OpenIddict and IdentityServer, on the other hand, will implement these things for you.
Regarding Openiddict - it is a kind of extension to simplify server creation based on AspNet.Security.OpenIdConnect.Server.
Initially, that's indeed how I was asked to design it. OpenIddict was created for non-experts who don't feel super comfortable with the protocol details of OAuth 2.0 and OpenID Connect.
While it will give you full flexibility to implement the user authentication part (e.g in your own authorization controller, using ASP.NET Core Identity or your own authentication method), it will handle the complex request validation process and make it transparent for your app, without drowning you with tons of configuration options.
Unlike ASOS (that tries to be as flexible and as close to the specifications as possible), OpenIddict generally comes with more restrictive validation routines that I personally consider as best practices. For instance, it will automatically reject authorization requests that contain response_type=token if the client is a confidential application, even if that's not prohibited by the OpenID Connect specification.
I am looking for an ioc container to use for asp.net webapi. Couple of the key feature we are looking for are as follow
Custom lifetimes
Built-in support for web request lifetime
Good integration with web api in terms of manage the dependency registration.
Mark Seemann knows his DI/Ioc and has an article on implementing it for Wep Api with Castle Windsor here. I don't know about custom lifetimes but it definitely solves the second and third requirements.
Castle is not as lightweight as say Autofac but it's been around for years and is tried and tested: I am using Castle for my Web Api and Mvc projects without issue so far.
Both should do the job though.
I personally like Unity. The reason why I use Unity is that it is build by Microsoft and with that you can expect that it is nearly up-to-date. Also I had prior experience with it and it has good support for ASP.NET Web API, but the final choice for or against a container is up to you. It really dependent on personal flavor.
There's a small part in the ASP.NET tutorials which talks about using Unity with Web API.
We are implementing a claims-based approach to security for our enterprise applications. I've been looking at the built-in support (with System.IdentityModel) as well as Windows Identity Foundation (WIF) but it doesn't look like either support Silverlight applications. I realize that SL4 doesn't support IPrincipal et al, but that shouldn't mean we can't still do claims-based auth.
Am I missing samples or documentation showing how to do so in SL4 or am I left to a home-grown solution?
I recently discovered that the latest version of the WIF Training Kit contains a sample application showing how to integrate WIF into a Silverlight client. It includes a version of the WIF IdentityModel code compiled against the Silverlight runtime. While not an ideal or even long-term solution, it gets me going.
Have a look at this by Dominic:
http://www.leastprivilege.com/UsingSilverlightToAccessWIFSecuredWCFServices.aspx
or this:
http://social.msdn.microsoft.com/Forums/en/Geneva/thread/fe890df3-8815-4d05-b293-d3c87f32e9e0