We are looking to utilize Multi Factor Authentication in a custom MVC App which connects to Kentico. I want to ensure i'm getting the right direction, is this the starting point: https://docs.kentico.com/k11/managing-users/user-registration-and-authentication/configuring-multi-factor-authentication#Configuringmulti-factorauthentication-Customizingmulti-factorauthentication
can we leverage the Kentico API to utilize the MFA functionality or do we have to write our own?
Given, the fact that Kentico MVC memebership is built on a good part on ASP.NET Identity it seems easier, to actually implement this with NET Identity.
Kentico MVC package is available on github for review. Package implements a user store in which Kentico (application) users are loaded per request and this store manages their authentication.
Store implements IUserTwoFactorStore which means store can be used with above idenity for multi factor authentication. It also has a retrieval method:
GetTwoFactorEnabledAsync
while SetTwoFactorEnabledAsync throws NotImplemented exception. Meaning you can have users stored and managed within Kentico backend and you can enable MF authentication for them via administration interface, while you can use .NET methods to have MF authentication on MVC site.
It seems easier than to actually reference Kentico DLLs for MF authentication in MVC project.
Related
I am going to create an web app using Dot Net Core. In future, i will also create mobile application for the same application. Now, i am in thinking the architecture of the project. I want to use WEB API core using Asp.net Identity Core. Also, i will consume WEB API in MVC Core application. But the question i have in mind that how i can handle ASP.net identity with MVC and WEB API? Do i need to include in MVC as well or only in WEB API?
I tried to think hard but still confuse. Need suggestions.
You can use token based authentication .
In a resource owner flow scenario , your client app( mvc application/native application) will consume your web api by providing user's credential , web api will validate the credential(using ASP.NET Core Identity) in database , If the username and password are correct then a JWT authentication token and the user details are returned. Your client app could validate the token and sign in user :
ASP.NET Core 2.2 - JWT Authentication Tutorial with Example API
Tutorial built with
Token Authentication in ASP.NET Core 2.0 - A Complete Guide
In addition, IdentityServer4 is a good choice when you want to roll your own full-fledged OpenID Connect authorization server that can handle complex use cases like federation and single sign-on.
So your question is maybe a bit open-ended for Stackoverflow and you don't really show what you have tried so far.
I will try to answer though. First you just need to start out with a template for your project. Start an MVC project in which you can easily have API endpoints as well. I would suggest splitting those in two projects for clarity - but if it is just a small personal project then you probably are fine having them in the same project. Microsoft have a pretty good resource on MVC:
Microsoft MVC walkthrough
For the Identity part. You would need some kind of authority for it to work. I suggest you take a look at IdentityServer4. Which offers an excellent walk-through of how to set it up and how to integrate it with Asp.NET Core Identity:
IdentityServer4
I'm using identity server 4 as an authentication server, and have successfully demonstrated authenticating clients for access to my MVC web application and my Web API application, both running on IIS under .NET 4.7.
The problem I'm having is finding the correct approach for ensuring clients are only able to access the endpoints they should after the authentication process. EG, I have two clients, one with a write scope, and one without. How do I ensure the one without is only able to access endpoints that will read my data and not amend it?
The best method I've found so far is to use an authorization attribute like this:
https://github.com/IdentityModel/Thinktecture.IdentityModel/blob/master/source/WebApi/ScopeAuthorizeAttribute.cs
However, this is marked as obsolete and I'm unaware of the version based on OWIN middleware is mentions. Considering my MVC and Web Api applications are unable to be updated to .NET core applications, what would be the best approach?
Since the scope claims are available within the ASP.Net pipeline you can implement your own access control filter quite easily. It may be that that particular library is obsolete but the practice of enforcing scope in an MVC/WebAPI filter is certainly entirely valid.
I'm using ASP.NET Identity 2 Framework (ASP.NET MVC 5) in a multi-tenanted application.
I can integrate a Facebook application easily. It can be configure it's scopes/credentials etc in Startup.cs.
But I have x domains and x Facebook applications, and I'll decide which credentials to use during runtime.
How can I change/set an external login providers settings dynamically rather than on application startup?
The Identity 2 Framework doesn't support setting or registering dynamic external login providers (such as being able to alter the Facebook clientId credentials for example). You will have to role our own solution manually.
The framework is based on OWIN and thus a controller can only pass messages to the authenication provider by the use of a shared context. The one that is provided by the ASP.NET Identity system doesn't support relaying these kind of messages (such as the credentials you want to alter). OWIN doesn't allow you to alter the settings of a MiddleWare object that has already been bound.
Further, the extension Microsoft provide for the Identity system for each of the main external login providers (i.e. Facebook) are structured using Internal classes that we cannot inherit from or modify. So this leaves us stuck.
You can role your own OWIN MiddleWare provider for facebook, and use a shared context - which is supposed to be the modern way of doing things. Or just use the regular MVC system to handle this. You could use the source code for their Identity Facebook Extension as a guide.
Scenario:
I have an ASP.NET MVC 2 site using ASP.NET Forms Authentication.
The site includes a Silverlight 4 application that needs to securely call internal web services.
The web services also need to be publically exposed for third party authenticated access.
Challenges:
Securely accessing webservices from Silverlight using the current users identity without requiring the user to re-login in in the Silverlight application.
Providing a secure way for third party applications to access the same webservices the same users credentials, ideally with out using ASP.NET Forms Authentication.
Additional details and limitations:
This application is hosted in Azure.
We would rather NOT use RIA Services if at all possible.
Solutions Under Consideration:
I think that if the webservices are part of the same MVC site that hosts the Silverlight application then forms authentication should probably "just work" from Silverlight based on the users forms auth cookies. But this seems to rule out the possibility of hosting the webservices seperately (which is desirable in our scenario).
For third-party access to the web services I'm guessing that seperate endpoints with a different authenication solution is probably the right answer, but I would rather only support one version of the services if possible...
Questions:
Can anybody point me towards any sample applications that implements something like this?
How would you recommend implementing this solution?
You can extend WCF to use Membership as authencation store and reuse the FormsAuth Cookie (send by the MVC site) to the browser by the Silverlight app.
I would recommend using an STS with Windows Identity Foundation so you can have your app use claims identity and then change authentication outside the app. For third party you can use Windows Azure Access Control Service (ACS). We are updating our guidance on this and you can look at the new code to show you how to do this at our codeplex site. The original book is available at Amazon. I would focus on the updated guide because it has ACS has websites and an active client talking to WCF. The client is WPF but it would similar for Silverlight.
For ASP.NET MVC extranet applications, what are the pros and cons of using SQL Authentication instead of the ASP.NET Membership API to handle security?
Gern, you are describing aspects of the same framework.
The asp.net provider stack is an abstract service layer that 'provides' common services to your applications.
The built in Sql providers are simply implementations that use Sql server as a backing store. The MVC framework and scaffolding provide all of the necessary adapters for using the default Sql providers.
If the built-in asp.net sql providers provide the functionality you require then the pro is that all the work is done.
Not sure what a con would be.
In regards to the possibility that you want to compare using Sql providers vs AD providers:
The AD/Token based providers Active Directory for authentication and access control and the implication is that a user must have a valid account setup in the AD in order to access protected resources.
The Sql providers allow you to define arbitrary users that do not require AD accounts.
The infamous grey zone appears when you have a large AD user base that you must support but must also allow for non-AD accounts to be established. At that point you will start to explore the exquisite joy that building composite provider stacks will bring to your life while it steals your sleep. But that is a topic for another book.
HTH