We are trying to achieve the multitenancy in our asp.net (Web forms) application. We are providing separate database for each tenant. We have one master database which stores the configuration string for tenant databases.
We are using Application_start (Global.asax) to go trough all connection strings and inject all session (alias) for each tenant. Every thing works fine.
We wanted to introduce the capability where we just create new tenant database and connection strings for it in master database and application should be able to serve new tenant without restarting Website(IIS restart).
Can I get some hint how can I achieve it without restarting web site?
Thanks
Shishir Kumar Mishra
Although this implementation is about testing with an embedded database, but it should be enough to give you an idea.
http://www.codeproject.com/Articles/18348/TDD-using-SqlCE-and-NHibernate
Related
If i had two different application running under the same solution but using different Databases can i share User credentials between those applications ?? any solution other Than The SSO and the Machine key in the web.config where the authentication is based on the default Asp.net Database ( i guess it's called the membership database )
if their is a solution could You please help
Are it two seperate IIS websites? And what are the real requirements you have? Just share some variables or move data from one application to another?
I'd think you'd probably better look into creating a service layer to receive and send information between sites. This way you can eventually seperate the two applications on different web front ends without problems.
This service layer can be implemented using different techniques like XML Web Services, WCF, or maybe you could look at the new ASP.NET Web API http://www.asp.net/web-api
edit:
Ok clear from the comments I got some more info:
Imho you could do two things: schedule a synchronisation using some mechanism (could be xml export / import) every day or so. But if you'd want realtime SSO, you could simply create a service on the webserver connected to the authentication database where the only functionality is to authenticate users. Something like a: bool validatecredentials(string username, string passwordHash). If you're not talking about thousands of authentication requests this will perform quite good using standard WCF or some other service technology. If you are talking about larger systems or implementations you should look at Claims based authentication, .NET has a technique called WIF to implement that. It works using a seperate STS (Security Token Service) to issue tokens with claims who a user is and what he is allowed to do, etc.
I'm developing a site that will display confidential readonly information,
with data fetched from a WCF service.
My question:
What is the best approach to user management across different information pages.
The service returns a collection with customer info after a secure login.
My idea is to have a Customer object class that is stored in session.
Is it possible to use things like HttpContext.Current.User.Identity.IsAuthenticated
followed by HttpContext.Current.Session["UserId"] without using a database with role-based security?
Would I be better off with a combination of local database, Linq to SQL or datasets rather than using
just class objects for data fetched from service?
thanks,
nakori
If you have no need of tracking the user's identity within your application, just use session as you indicated.
But the HttpContext.Current.User.Identity.IsAuthenticated and such relies on the user having authenticated with your site in some way or another (or it will always come back as false). Authenticating with the web site doesn't necessarily need a database though. You can setup users directly in web.config, xml files, or use AD or some other authentication mechanism that doesn't use a traditional database.
But unless you need to authenticate the users, you can probably do what you want using the server's session object and/or cookies.
You don't need a local database - but best practice is to have the user authenticate. The two options are via a database and or via AD if this is an internal site.
You might as well create a new WCF service to perform the authentication since you've already got your database functionality separate. This will also let you access databases that aren't local.
Our ASP.Net application uses SQL Server 2008. Most of the time the application connects to SQL Server using a SQL account with very limited access rights.
However once in a while we need to be able to create a new database on the fly. As such we need elevated permissions and I am a little nervous about storing this connection string in Web.config, which may be in a DMZ.
We are considering writing a Windows service to run on the SQL Server machine (i.e. not in the DMZ) which will monitor a table for requests to create a new database, but it seems like overkill.
Any suggestions for alternatives or recommended practices?
You can store the connection string in the registry and protect that by limiting access to the specified registry keys. That's one of the ideasI ran across back in .Net 1.1 as a reccomendation from Microsoft. The concept is still the same in 2.0 and up. Here's a link to the documentation.
http://msdn.microsoft.com/en-us/library/aa302406.aspx
It sounds like you're already concerned about security, so I'm guessing you've read through or at least run across the "Building Secure ASP.Net applications" section of the MSDN library. The link above is in the how-To section of that guide. Hopefully this is helpful.
Also, if you DO store your connection info in the web.config, at a minimum, encrypt those portions.
And I just ran across this. Probably more like what you were looking for.
http://msdn.microsoft.com/en-us/library/aa302388.aspx#secnetch08_storingsecrets
If you are using mixed mode authentication in your database connection strings (I.E., username and password) then you should encrypt the web.config connectionStrings element.
What about using a stored procedure to create the database? I haven't tried it; the one part I'm worried about is specifying the database name through a variable. By using the stored proc, you only need to grant your web id execute access on the stored proc.
Another option would be to create a console app (instead of a service). Then use a job scheduler to run the job every 15 or 30 minutes or upon request if you have a capable scheduler. That will be much simpler than writing a service; it just isn't an "instant" process. I do this for some Active Directory work that triggers off of web site updates (I didn't want to give my web id Domain Admin priveleges).
I have my default website in IIS7 bound to an ASP.NET application. This application is using the ASP.NET State Server to store session data. I would like to add an additional ASP.NET MVC application to this website. Is it possible to share the session between these two applications using the state server? I've read that there are ways to do it storing session data in SQL Server, but I can't find any documentation on doing it with the state server.
Thanks,
Nathan
Best advice I have to to switch to SQL Server for the session state store. It's not difficult to set up if you already have SQL Available and use the following technique:
Sharing sessions across applications using the ASP.NET Session State Service
For this situation you are probably best to write your own custom session state provider that runs on a SQL database.
details are here:
http://msdn.microsoft.com/en-us/library/aa479034.aspx
the reason i'd write a custom provider is because simply settings up an SQL session provider will not be enough as the applications will use different session keys and therefore will not share state between them. by writing your own session provider you can have fine grained control over the whole process and therefore override the checks in place using the default sql session provider.
I'm in the process up changing a single SQL DB website (ASP.NET/VB.NET) into a multitenant app, where each client has their own database.
In the old site, all the ASP roles, logins and providers pointed to the single database.
Now we have multiple databases, I'm wondering what would the best architecture/techniques to use. There is one database that configures the tenants, such as the company name, various settings (that would normally be in a web.config) and the connection string to their tenant database.
Should we have all the membership & role stuff in the single database that configures the tenants or do we have membership & roles in each individual tenants database? Option 2 seems tricky because I think ASP.NET only likes one set of RoleProviders defined in the web.config.
Has anyone tried this before or got any recommendations?
If you're using the ASP.Net Membership model with the built-in providers' then putting them into one DB is the easiest as you indicated.
One option, and I've not tried this, is to define in your web.config file a provider for each tenant. This would allow each tenant to have their own membership db, and allow you to avoid username collisions between the tenants (if this is a requirement).
You should be able to configure the the ASP.NET membership database connection string at runtime. This thread has a few options including a custom membership provider or changing the value early on in the request lifecycle via Global.asax.cs.