I am trying to provide authorization to the user, using DocumentDb at the backend - But I am unable to find any resources regarding the same. The documentation provided is for SQL based ones (https://docs.asp.net/en/latest/security/authentication/identity.html).
Any help?
To provide you with a starting point, there are several important issues to bear in mind when looking at using Identity with ASP.Net Core:
Framework Compatibility
You mention that you will be using ASP.Net Core, and this can be used with either .Net Core, or the 'full' .Net Framework (e.g. .Net Framework 4.5.1), which can be specified in your project.json under the frameworks property.
The Microsoft DocumentDB native .Net client does not support .Net Core; so, you must configure ASP.Net Core to target the 'full' .Net Framework. If you are unsure how to do this, you can create a new project in Visual Studio 2015, and select the 'ASP.Net Core (.Net Framework)' Project Template; the project.json will have its framework property correctly configured for you.
'Identity' Version
There are several versions of ASP.Net Identity; be aware when selecting a provider, that most currently reference ASP.Net Identity 2.2.1; however, the latest version is 3, released alongside ASP.Net Core, supported by the NuGet package Microsoft.AspNetCore.Identity 1.0.0, which has some differences and additional features. (Note that you can use this latter package with the full .Net Framework.)
No Official Implementation
Microsoft has decided not to create an official DocumentDB implementation for ASP.Net Identity, citing that 'there are two community projects available' (reference here)
Third-Party Support
Of the available third-party implementations, this one by Adrian Fernandez is the most widely used that provides support for ASP.Net Identity 3 using the Microsoft native DocumentDB client. Samples are included in the GitHub repository. (Please see update below.)
Example Usage
An example of using this DocumentDB provider with ASP.Net, including additional features, can be found here.
An additional example of using ASP.Net Core with the Microsoft DocumentDB provider can be found here.
I have written my own Identity 3 provider for DocumentDB; if I release this on GitHub I will update this answer with a link.
UPDATE 19/04/2017
For those looking for a solution, I now recommend the AspNetCore.Identity.DocumentDb project by Bernhard Koenig. It is feature-complete, includes Unit Tests, and a sample ASP.Net Core project. Also available via Nuget. It supports netstandard1.6 an net46 profiles.
my understanding is the Microsoft made it possible to use Mongo drivers with DocumentDb so maybe you could use this Mongo implementation for asp.net core identity
or google further for existing work that others may have done in this direction.
To implement it yourself you would need to implement at minimum IUserStore and IRoleStore you can also refer to the EF implementations UserStore and RoleStore for inspiration and guidance on implementing those.
The best solution would be using a DocumentDB provider for the .NET Core Identity framework. But there were none so far which is why I created AspNetCore.Identity.DocumentDB and decided to publish it on GitHub under the MIT license.
It is a port of an existing mongodb provider for .NET Core Identity and stores Claims, Tokens & Logins as nested objects. Although one could use DocumentDB with a mongodb interface it's recommended to use the native SDK if possible.
The library is already quite stable and available as a NuGet package.
Notice:
The DocumentDB SDK for C# itself does not support .NET Core as a target platform in the stable release. Fortunately Microsoft is already working on adding .NET Core support and published a preview of the DocumentDB SDK with :NET Standard support at the Connect(); 2016 event.
AspNetCore.Identity.DocumentDB supports both SDKs.
.NET Standard is a specification of APIs that should be available on all .NET runtimes and is currently supported by .NET Core and .NET Framework.
Related
In .NET framework we have support of Creating Help Page for Web API.
https://learn.microsoft.com/en-us/aspnet/web-api/overview/getting-started-with-aspnet-web-api/creating-api-help-pages
Does this feature supported in .NET 6. We are migrating our legacy ASP.NET framework application to .NET6.
How to migrate this feature to .NET6? If it is not supported in .Net6(.net core) how can we achieve the similar functionality in .Net core
I am trying to migrate this feature to .net core but I am facing issues on how to load the app data, register HelpdataConfig in .net core.
ITNOA
As you can see in ASP.NET help page for ASP.NET Core Web API, the Microsoft.AspNet.WebApi.HelpPage is for ASP.NET and does not for ASP.NET CORE or .NET 6, so you have to migrate this library to some popular Web API documentation libraries like Swagger
As you can see in ASP.NET Core web API documentation with Swagger / OpenAPI, you can use below documentation
By Christoph Nienaber and Rico Suter
Swagger (OpenAPI) is a language-agnostic specification for describing REST APIs. It allows both computers and humans to understand the capabilities of a REST API without direct access to the source code. Its main goals are to:
Minimize the amount of work needed to connect decoupled services.
Reduce the amount of time needed to accurately document a service.
The two main OpenAPI implementations for .NET are Swashbuckle and NSwag, see:
Getting Started with Swashbuckle
Getting Started with NSwag
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/
For a .NET Core 2.0 project, I used Microsoft standard health check libraries which are clearly documented based on code for .NET Core 2.0. Since less than a month, suddenly, this is deprecated. The new readme file, refers to an alternative for .NET Core 2.2 .However, the version of .NET Core that is production ready, recommended and has long term support, is version 2.1 which is exactly what I use now for a new project.
So I am in trouble. What is the supported way of implementing health checks for .NET Core 2.1? This used to be clear for .NET Core 2.0 and shall be clear for .NET Core 2.2 but for .NET Core 2.1 it is unclear what I should do.
You answered your own question actually, with the reference links.
ASP.NET Core 2.2 comes with its own official heath check, see Docs and the ASP.NET Core 2.2.0-preview1 blog post for the new health service.
You can use either one (2.2 or your old solution) for the ASP.NET Core 2.x life-time. Since the old one is deprecated it won't be updated for newer versions of ASP.NET Core, but you should expect it to work for the 2.x lines.
By the time ASP.NET Core 3.0 is out and you want to migrate to it, you should switch to the health services introduced in ASP.NET Core 2.2.
General consensus about new features in minor versions (which replace or change previous behavior) is to support them for the current main version and drop the old functionality in the next major, i.e. the new [ApiController] attribute and automatic model validation was added in ASP.NET Core 2.1. By default, the 2.0 compatibility will be used and the new behavior won't be available unless you opt-in. Once 3.0 is released, the old features/behavior will be removed and only the new one will be used.
Our University has migrated to a SAML based authentication/authorization method using Shibboleth.
I have been researching for at least a day on how to use SAML with .net core web applications. I can't use Identity server 4 because it is for OaTH/Open ID. I found some documentation on msdn which points to a commercial implementation. I came across this SO answer from a year ago saying Kentor may support it in the future but couldn't find anything on the github page about support for .net core or a .net core sample web app. As of January it was still planned but no date.
The University has the identity provider running. What I don't understand is the following:
How do I set my web application to use that identity provider?
How do I check if that identity provider has already been authenticated for another application, so SSO use?
Also, any sample applications that use SAML without commercial plugins would be greatly appreciated.
ITfoxtec has a ASP.NET MVC Core 1.0 SAML2 plugin, but it requires the .NET Full Framework, and won't run on linux. There's some missing APIs that are preventing full .NET Core support right now for SAML2 (around Crypto XML namespace). https://github.com/ITfoxtec/ITfoxtec.Identity.Saml2
Not exactly what you're looking for I know, but it's an interim solution until probably .NET Standard 2.0, which will probably bring the missing API's to .NET Core.
ITfoxtec Identity Saml2 support .NET Core 2.1 (without the .NET Framework) from version 3.0.0. Project: https://itfoxtec.com/IdentitySaml2
ITfoxtec Identity Saml2 MVC Core support ASP.NET MVC Core 2.1. NuGet package: https://www.nuget.org/packages/ITfoxtec.Identity.Saml2.MvcCore/
With ASP.NET Core 1.0 release one can run on either .NET Core or the full .NET Framework per the documentation here. I'm trying to understand the latter option of why one would select ASP.NET Core + the full .NET Framework?
I understand the difference between the full .NET Framework and .NET Core. However, if I wanted to use the full .NET Framework, why not just use ASP.NET 4.6? I thought the idea was a 1-2 punch with ASP.NET Core atop of .NET Core allowing the slew of benefits like cross platform deployment, modularization, ability to deploy to a Docker container, performance, etc. Without .NET Core I don't believe anything on that list is still valid, so what is the use case for the full .NET framework + ASP.NET Core? What does ASP.NET Core on it's own still provide to me without .NET Core?
.NET Core allowing the slew of benefits like cross platform deployment, modularization, ability to deploy to a Docker container, performance, etc.. Without .NET Core I don't believe anything on that list is still valid
The only benefit you don't have if you choose the full .NET framework over .NET Core is being cross platform. All the other benefits of deployment, modularization, docker, performance, etc... are still valid.
We actually run our ASP.NET Core web app on the full framework and now we enjoy the benefits of having Dependency Injection as a 1st class citizen, having NuGet built in, having an lean HTTP request pipeline which makes our performance better, open sourced (so all the issues can be solved by a short visit to GitHub), modularity (still have to come across something we couldn't customize to our own needs after almost a year now), and so on. And we know we don't need to deploy on any other OS than Windows, so we can still have all the benefits of the full framework.
Update from Tseng
Well, you can still target full .NET Framework under Linux for example. There you need mono 4.6 installed there. There are some limitations as not all classes are implemented in mono, but a majority is and around the corner case (i.e. encryption) you have to work around
Update from atconway
It's also worth noting at the time VB.NET is not supported by .NET Core if that's a requirement.
However, if I wanted to use the full .NET Framework, why not just use ASP.NET 4.6?
If I use ASP.NET 4.6 instead of ASP.NET Core 1, then I won't be able to use ASP.NET Core MVC. None of the features on that documentation page would be made available to me! I would have to build an MVC5 application. Boooo!
I'm trying to understand the latter option of why one would select ASP.NET Core + the full .NET Framework?
I'm assuming that another way to ask this would be: "why would you take the red path when you can take the brown path?"
One argument for doing it this way is deployment. If you've got a bunch of existing Windows servers with IIS on them, you're going to need to install additional software on each of them and set them up to run Core applications. IIS just becomes a reverse proxy for your .NET Core app.
However, if these apps were built on the .Net Framework instead, you wouldn't have to do this. You could still use web deploy (for example) to move them onto the servers. Maybe you've got some other existing IIS configuration settings that you don't want to migrate.
Using ASP.NET Core 1.0 targeting the .Net Framework, you can get the benefit of the new features in ASP.NET Core MVC without having to change your existing infrastructure.
One important benefit of using Full .NET framework with Asp.Net core is availability of mature libraries and frameworks that are developed mainly to target previous version of .NET.
But by passing of time and implementing more and more libraries to target .NET core and developing more features for .NET core itself this benefit may fade out.
Having to leverage legacy technologies like OLE DB that will never be implemented in NET Core System.Data is another reason.
One thing to consider is that it can be a migration path. Say, for example, you have an existing ASP.NET 4.6 application that you intend to migrate to .NET Core. You want to take advantage of ASP.NET Core features like TagHelpers, Dependency Injection, etc., but you aren't ready or able to use .NET Core framework. So, you develop the ASP.NET Core application, targeting just the .NET full framework. Then, you take the next step and multi-target, going for both .NET full framework and .NET Core framework. This gives you the flexibility to easily deploy to IIS with the full framework or cross-platform with the core framework. From there, you can decide if you want to eliminate the full framework or not.