When do asp.net role providers live and die? - asp.net

I am working with a custom role provider in asp.net and it appears that once the provider is loaded into memory, it doesn't drop out of memory until the web application is restarted (like when the web.config file is changed and saved). Further, all of the requests to that web application seem to utilize the one instance of the role provider.
So my question is: When does asp.net create instances of role providers? And what is their life span? When does asp.net create new instances? And is there a way to force asp.net to refresh the current provider instance by dropping the old instance and creating a new one?

The design of ASP.NET assumes the providers are stateless objects. Therefore, you should design your provider in a manner that you won't need to know about when it is created and when it dies. Basically, if you really want to do that, you could put the actual logic in a different class that its creation and disposal will be handled by a proxy class that you introduce to ASP.NET.
Also, ASP.NET does not guarantee when it will create the role provider object. It's something like static constructors. You should only rely on the fact that they do exist whenever they are needed.

Related

Microsoft Asp.Net Identity 2.0 - Entity Framework vs. Custom Provider

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.

Active Directory in ASP.NET Web Forms Application

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.

Handling user authorisation with ASP.NET

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.

WCF Cache vs. Page.Cache

I've got two different, but closely related ASP.Net web applications that use the same data on some pages. In both applications I am using the ObjectDataSource control, have EnableCaching="true", and use the same CacheKeyDependency value in both applications.
I would like to make it so that when a new record is inserted or deleted in one application, it clears the cache in both applications. I began by simply clearing cache by using Page.Cache, but soon realized that it does not clear the cache in the other application. Then I added a WCF service to each application; each service clears the cache object in the application it is hosted in. Except that it doesn't...
First, I discovered that System.Web.HttpContext is always null in WCF. Then I tried instantiating a System.Web.Routing.RequestContext object, but its HttpContext object is always null as well.
It all boils down to this: If I set a Page.Cache object, can a WCF service access that same cache object, if the service is hosted in the same application as the page?
Yes, you need to enable ASP.NET integration for the WCF service. This involves setting the aspNetCompatibilityEnabled attribute for the serviveHostingEnvironment element in config as well as adding the AspNetCompatibilityRequirementAttribute attribute to you service class to indicate that you support it.
More on this subject can be found here on MSDN.
The main challenge with cache in two applications is that the cache can be stored on seperate machines, or if they are on the same machine, in different application pools.
One way you can do this is to allow both applications to use the same cache. One solution for a distributed cache that runs out of process is Appfabric caching.

Authenticate a ASP.Net Webpage against a WCF Membership Service

I have a Webpage made with ASP.Net and another set of tools like a WPF, Windows Forms applications. Is mandatory that the ASP.Net webpage and all the set of applications be authenticated against the same ASP.Net membership provider database.
What I want to know is the best way to authenticate using a WCF service that uses ASP.NET membership provider for the authentication. Is anything made out of the box for authenticate a ASP.NET webpage against a WCF authentication service? I have to implement a Custom Provider? Because the Membership in ASP.NET Webpage fill the IPrinciple User property with user information and I want the same behaviour with a WCF service authentication.
a custom membership provider is how i have done this before. it worked pretty well. my group made the mistake of making the wcf service match the interface of the membership provider, which was unnecessary and messy. if you choose to go this route, i'd recommend making your service contract on your own as you want it and implementing your provider to consume that.
if i was doing it again, though, i wouldn't use wcf at all, but rather just use a membership provider (existing or a custom one, depending on your needs) for the asp.net application that talks directly to the database rather than a wcf layer and have a shared assembly the other tools could use that talks directly to the database. even having common code in a wcf service tier. i don't think using a service really provides a whole lot that you couldn't get by just using a common assembly. the asp.net membership provider is going to be something separate anyway.
this is assuming you are within an environment where you can just have the desktop tools connect to the database. if this is an internet deployed scenario, you probably do need to do this through some kind of service, and wcf is a great candidate for that. it's probably a shorter path, though, to use an existing membership provider and build your wcf service on top of the database that goes with that than to build a membership provider that consumes the wcf service. i don't think it would be a bad choice to do the latter, but you'd probably be better off with the former. this, of course, depends on a lot of factors, though.

Resources