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.
Related
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.
I notice there are several different namespaces/classes for accessing Active Directory. What are the differences between using the following ?
System.DirectoryServices.AccountManagement
System.DirectoryServices.ActiveDirectory
System.Web.Security.ActiveDirectoryMembershipProvider
The items under AccountManagement deal with working with various LDAP type data stores. Not just Active Directory, but NDS and WinNT as well. If you know your backing store is LDAP compliant or may switch between various LDAP stores then this is probably the best to use.
The ActiveDirectory namespace is specifically for AD. Usually you only care to use this if you are going to stay strictly within an AD environment.
The ActiveDirectoryMembershipProvider has a slightly different focus. This is usually used by Web Apps as one of the membership providers. Other membership providers include the SqlMembershipProvider or even custom ones that you might create. This is used when your backing store might be AD, but could also be changed to use SQL server or some other random store in the future.
In summary, it all boils down to how your app currently functions and how it might grow in the future. If you have a desktop app, then use the System.DirectoryServices namespace. If you have a web app that might be deployed into unknown environments, use the membership providers.
Note that I have used a combination of a SqlMembershipProvider and the System.DirectoryServices space together in some apps. Specifically to authenticate into an LDAP store (AD/NDS) while authorization stays in my app.
I am a newbie to ASP.NET - so what is the pattern to use Isolated Storage vs. Session state for web applications?
I have a use case where when a user logs into the application, I need to create his profile information which will persist throughout his session.
Does it make sense to store this in session or should I use Isolated Storage (assuming the client is on a Windows machine)
Thanks!
ASP.NET has a profile provider that's built to store a user's profile.
You could use your own provider that's session backed if you really only want the profile to last for the duration of the session.
Your last comment makes me think you want to use isolated storage on the client machine; I don't think you can access isolated storage on the client from a browser w/o an ActiveX control or something like that.
Isolated storage is not used in asp.net applications for storing profile info - this is generally used in .net apps running on the client side.
To get profiles up and running, see any of the many posting on it.. a good one by Dino Esposito
http://msdn.microsoft.com/en-us/magazine/cc163724.aspx
and
http://msdn.microsoft.com/en-us/library/2y3fs9xs.aspx
The configuration is there by default but in visual studio you will want to bring up the admin site for your web app to make sure everything is setup.
Using web applications or web sites also gives you different access to profile properties. One will strongly type them, one will not.
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.