We're planning to use standard ASP.NET user authentication for our application. However, by default this requires us to have our user database on our web server in the App_Data folder.
This is usually a big no-no for us - our databases are all behind the firewall and all access is done via a WCF Service layer.
If the database was on a different server, but directly accessible from the web server then this still vioates our usual architecture rules.
Should we worry about our user database living on our web server? Does ASP.NET offer an out-of-the-box alternative?
NOTE: We're using .NET 3.5 and SQL Server 2005
You can install the neccessary db tables etc. in any SQL Server database.
Use the aspnet_regsql.exe Wizard found in C:\WINDOWS\Microsoft.NET\Framework....... to set up the target database.
Then simply update the connection strings in the provider configurations in the web.config.
Yes and Yes.
If you ever need to move to multiple web servers you shouldn't have the user data on one of those servers.
There are multiple was to do this, but check out this link for details on one MSDN How To: Use Forms Authentication with SQL Server in ASP.NET 2.0
you can create your own Custom membership provider by overriding the methods and properties of the following abstract class: public abstract class MembershipProvider. Once you override them, then you can use any valid datasource to authenticate the user. For example, you can use MYSQL, SQL server or even XML file to authticate your users. These provider models are really really cool.
Yes, you should worry. No, there is no out-of-the-box solution. ASP.NET only ships with a SQL Membership Provider and an Active Directory membership provider (reference). You will have to use a custom membership provider to provide your functionality.
Related
I have a WinForms application that accesses an Azure SQL database via a WiFi connection. I would like to know how I can use ASP.NET Identity to register and login a user with their username and password. I have seen how a sample ASP .Net MVC 5 project does most of the work for you but can't seem to duplicate the functionality in my WinForms app. Appreciate any help.
There are many different ways to accomplish this, I would start here: http://msdn.microsoft.com/en-us/security/aa570351.aspx
One way is to use domain security, another way would be to use ASP.Net Membership by adding the necessary configurations to your app.config along with a reference to System.Web. In your app.config you could use a SQL Azure connection string.
I am writing a new web site and am looking at Asp.Net Identity 2.0. Out of the box, it uses Entity Framework for all of its data access. For the rest of the site, we were creating middleware web services for data access. Our original plan for security sake was that the web servers would talk to middleware and middleware would talk to the database via Entity Framework. We had planned on blocking via firewall database access from the web server.
I see that I can create a custom provider for Identity 2.0 and it in turn could use middleware for it's data access.
Here are my questions:
Is it more secure to not allow the web servers to have direct database access?
If it is more secure, why would Microsoft not build it that way out of the box
If you were starting from scratch like we are, would you recommend using entity framework or writing a custom provider that goes through our middleware layer?
Thanks.
1.) It can be secure. I don't see it as a security issue but coupling issue. What if you want to upgrade or change from Entity Framework in the future? What if you want to change from Identity 2.0? What if you want to upgrade one but you can't because the other doesn't support it yet.
2.) Microsoft wanted to promote it products first and foremost. For simplicity sake if your ok with Entity Framework and Identity 2.0 and don't mind how coupled they are it could be perfectly fine solution.
3.) How much time/effort can you afford to spend on the custom provider? It might not be worth the effort to create your own provider.
Asp.NET Identity out-of-the-box is actually Asp.Net Identity on Entity Framework. It generates a database, connection string, the model files, the controllers and a context class for you, which you can redirect to your own database for it to generate the Identity tables within. Everything is very secure, and they've taken care of a lot of the authentication/password hashing for you. I wouldn't say it is worth it to create your own provider, but you can also create your own provider within Identity if you want. Identity 2.0 is great. Very easy to add custom table properties, etc.
I'd like to make an OOB Silverlight app based on the Silverlight Business Application template in Visual Studio. The template uses the default ASP.Net membership provider. I understand how to use that to add users and roles, etc. I've found plenty of tutorials on that. What I'd like to be able to do, is configure the Silverlight template so that it uses an existing ASP.Net membership base. We'd like this app to have a companion website (ASP.Net based).
To clarify: We've been able to setup an ASP.Net website and have created a SQL database with the required tables (aspnet_Users, aspnet_Membership, etc.). I'd like to configure a Silverlight app to access the same users and roles that are in those tables.
Can anyone help me out in terms of what I'd need to put in the Web.config? Do I just need a connection string? I'm new to ASP.Net authentication, but I'd rather use what ASP.Net gives me out of the box than have to write my own authentication service. I feel like this should be really easy, and is just a matter of pointing the Silverlight app in the right direction.
I'd like to use Silverlight 5 and .Net 4.5 if I can but I don't mind using an older version of either if it makes things easier.
You can just point the connection string to the existing database.
From this answer:
You can point your connection string for authentication to a database that all application can access.
So if you have the default database that .NET creates, you can point your other application to that as well for authentication.
When creating a new Silverlight 5.0 business application, the authentication and authorization code is automatically generated. All the user info and roles are by default saved in the aspnetdb mdf file. My questions are:
Is it normal practice to keep user authorization/authentication data in separate database from your business related data, or should I copy the tables into my main database? I see that current implementation involves ApplicationId field, so it means that it can store data for different apps? Maybe there is some common database on the web server for all Web apps (just guessing)? :)
If I am to keep the user's info in a separate database, how to relate the data between these two databases? I mean, I will have UserId referenced in some tables (business rules)? My business data is using identity PKs and aspnetdb is using UniqueIdentifier, is this a problem?
When a user registers on the site, how do we assign it roles in production? There is a ASP.NET Configuration tool within Visual Studio, but what about the production environment? Should this be coded in the Web project?
What is the best practice for handling authorization / authentication of users in cases where the application always require authentication?
You shouldn't use the defaut ASP.NET authentication implementation in your production App: It uses a local database (the mdf file) because it works out of the box. However, You are not limited by this solution:
You could configure ASP.NET authentication (and role) provider to use your real database, allowing you to better integrate it into your existing data. To better understand the full process, see http://msdn.microsoft.com/en-us/library/6e9y4s5t.aspx and the linked pages. ASP.NET is able to generate all the required tables in your db by itself.
You could override the default authentication mechanism with your own. In this case you only have to edit the Services/AuthenticationService.cs in your web app project. The AuthenticationService class inherits from AuthenticationBase, and allows you to override quite a lot of membership methods with you own implementations.
I have an asp.net mvc application that I'd like to use forms authentication with two other asp.net apps that don't have the same machine key. Any thoughts on this? I don't have control of the machine keys for the other apps and they aren't the same.
You can point your connection string for authentication to a database that all application can access.
So if you have the default database that .NET creates, you can point your other application to that as well for authentication.
If you use the Database Publishing Wizard from MS then you can take the created database and copy that to any SQL database and then point each applications membership provider at that database.
Hope this helps.
You can also delegate you authentication operation to a service and use it from each app.