My web database server is being moved from the DMZ to the company LAN (don't ask why!). The downside of this is that my MVC 4 website is now gonna have to talk to an app server with web services (or web api) to get to the database. This isn't a major headache for most of my stuff, but I'm using the SimpleMembershipProvider for user authentication and that seems to need direct access to the database.
Is there any way to get SimpleMembership to talk to a web service or do I have to use a custom membership provider instead ?
I'm faced with the same situation, and while I haven't written or tested the code yet, I'll be writing a class to inherit from SimpleMembershipProvider and overriding the methods to call methods from the service (web api).
Is this the approach you ended up using?
Related
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 am facing a problem and I don't know if my solution is do-able. I have an ASP.NET MVC app which do request to a WCF service (both are hosted in IIS).
In the web app, I identify each user by Windows authentification and get their groups, roles, etc. from active directory.
BUT according to user groups, I need to change some settings in my WCF service. In my idea I'm looking a way to change the settings of WCF service (it need to be in the web.config, mandatory) and I'm really not sure if it's possible, because I think each call to the WCF should create a new instance of web.config, but for now it's just a simple file.
What do you think ?
Thanks !
I am currently developing an ASP.Net MVC web application that requires username and password authentication. I started looking into using ASP.Net Identity for this however I have a very important requirement, the requirement is that the web application itself has no direct access to any databases, all DB Access is to be exposed to the application via an internal REST service. This is due to certain security polices we follow.
I realise that ASP.Net identity is capable of supporting external authentication methods but my question is split into 2 parts.
1) How would I configure ASP.Net Identity to use my custom REST service for authentication?
2) How would I go about developing a service that can be used by Identity for authentication ? (what would need to be returned from the service to ASP.Net Identity)
Any help on this would be most appreciated.
I just did what you are asking about. First, as FPar suggested, you need to implement an IUserStore and pass that to your UserManager. Your custom IUserStore will implement the interface, I used Resharper to generate stubs, but instead of using entity framework, you will use HttpClient to make calls to your REST service.
The REST service will have one action on a controller, I called my identityController, for each of the interface methods you actually need. I implemented the userstore, userloginstore and the rolestore, with code for about 10 calls I actually used. The identitycontroller then is what actually accesses the database.
I also retained the fully async pattern, using async REST calls and Database looks, both with and without entity framework. A shortened version of my data access code is in another question here, regarding IUserLoginStore::AddLoginAsync. In that class I actually used the original entityframework implementation of the user store for part of work, and eventually settled on plain (except for async) ado.net for the parts I couldn't make work that way. The tables are simple enough, using your ORM of choice would not take a lot of time.
Good luck!
You want to implement your own IUserStore and then pass a reference to the UserManager. Look into the Startup and the IdentityConfig files in the standarad ASP.NET MVC with individual user account authentication, to see, how to use them.
You can look here for an IUserStore implementation with entity framework. This is a template, you could start from and change it to your needs. However, you don't have to implement all interfaces, just implement the interfaces, you really need. The UserManager is able to handle that (it throws an exception, if you call a method, that requires an interface, that you don't implement.)
These are two excellent articles on this subject:
http://www.asp.net/aspnet/overview/owin-and-katana/owin-oauth-20-authorization-server
http://www.codeproject.com/Articles/762428/ASP-NET-MVC-and-Identity-Understanding-the-Basics
I've desgined my ASP.NET MVC application using the Domain Driven Design, and I got the following projects:
MyApp.Core - the app core, contains the domain models etc.
MyApp.Infrastructure - the app main infrastrucutre, contains implementation for the domain model storing (repos etc.) using EF.
MyApp.Web.Core - domain models, services declaration (interfaces) and such only for web (e.g. IFormAuthenticationTicketSupplier, IOAuthAuthenticationProvider etc.)
MyApp.Web.Infrastructure - web implementation
MyApp.Web.UI - ASP.NET MVC standard application.
This application should be used by enterprise with multiple servers, etc. Currently, the application calls a service in the infrastructure layer at the controllers, which uses Repositories and EF. I can connect to the DB server using the connection string.
When digging about this topic at Google, I've read that some approches taken when creating an enterprise application are create an Application server and Web server. In the application server - storing a WCF service, and in the web server just calling it.
I'd like to know if I should do so (if creating a WCF service is the right and required approch when dealing with enterprises):
- Why should someone not just use the Services in the controllers and instead use an API?
- In case I'm using an API, it won't slow down the response? since even if the computers are on the same network, I still open an HTTP request.
- If I should use WCF, or ASP.NET WebAPI?
Thanks for any feedback and help!
First, regarding your projects, is there a need to split up MyApp.Web.Core, MyApp.Web.Infrastructure and MyApp.Web.UI? Sure they may be separate responsibilities, but sometimes dependency hygiene trumps encapsulation. You can always leave them in separate folders and namespaces. I wouldn't extract something into a separate project unless I needed to reference that as a library from elsewhere.
As far as the application service, that also depends on your needs. If the only place that would call that application service is the ASP.NET MVC app, then there isn't much of a need to extract an application service. There are some benefits however. One is that you don't have to worry about all of the dependencies required for a service - you just references it via Url. And of course you have the ability to call the service from places other than the controller, although the MVC controller can act as a pure HTTP service as well. You also have the ability to deploy updates to a specific service without releasing the MVC app. But you do have the burden of maintaining a separate service. If you do go that route, go with the WebAPI, WCF is just too much abstraction.
I started my project using ASP.NET SIMPLE MEMBERSHIP. Now I have the necessity to create a WPF application which can add users to SIMPLEM MEMBERSHIP tables.
In the ASP.NET, I've identified that this is the function to create new accounts:
WebSecurity.CreateUserAndAccount(model.UserName, model.Password);
What would you suggest to implement this feature in a desktop application. I was thinking creating a WCF Web Service, but I don't know how difficult could be creating it.
You could use WCF but probably the simplest solution is to include the Asp.net Simple Membership Tables as part of an Entity Framework Model and use the model from within your WPF app. Check out this post for more details.
That would, of course, require direct access to your SQL Server and either a SQL Server account with access to the tables referenced from the EF model would have to be used or the app users would have to have access to the SQL Server through integrated security (if using mixed mode authentication with your SQL Server).
Why bother?
I would simply have yours users go to a link and register for an account online through an asp.net page. Once registered, offer the WPF/windows client as a download. This stuff is already pretty much all built-in.
That link might help: http://weblogs.asp.net/jgalloway/archive/2012/08/29/simplemembership-membership-providers-universal-providers-and-the-new-asp-net-4-5-web-forms-and-asp-net-mvc-4-templates.aspx