I have a Visual Studio solution that consists of an ASP.NET website and a Lightswitch (soon to be 2 LS apps). I have configured everything so that a single login allows the user access to both apps. Currently both apps and the aspnetdb database are all on one machine.
Eventually, I want all three apps to be Azure websites with authentication via an Azure SQL database.
I want move the aspnetdb authentication database to an Azure and deploy the second LS app as an Azure website. Eventually the other 2 apps will be migrated to Azure, but in the meantime they will remain on the old server.
My question is are there any extra security issues I should be concerned with this arrangement? I have never had authentication and websites on different servers.
I don't think there are extra security issues as long as you're happy with the security around the connectivity to the SQL Database (which is based on HTTPS).
I do, however, think you should consider using Windows Azure Active Directory instead which will offer a potential cost saving and reliance on recent standards for authentication. if you haven't already look at this walkthrough. it does not talk about LS but rather an MVC application, but you should be able to see the setup process
You replied my question late, and accepted the answer. Anyhow, I'll answer your question so that this might be able to safe your time in the future.
If you want to host in Azure, you should not use Legacy Membership Provider (in which tables are generated using aspnet_regsql.exe).
Instead, you want to use new ASP.NET Universal Providers which is SQL Azure compatible.
any extra security issues I should be concerned with this arrangement?
You can configure to allow certain IP address(es) to access to your SQL Azure DB from outside of Azure. However, if someone knows your SQL Azure's username and password, they can access your Database within Azure.
Basically, you should be fine as long as nobody know your SQL Azure DB's username and password.
Related
I am totally new to Azure and have been asked to move websites to Azure hosting.
Moving to Azure hosting do seems to an issue but problem seems to be with the asp.net session state, our website which are developed using asp.net 4.0 & MVC & some of the website are quite old developed few years back around 2013-2014.
My big worry is how to choose session state or third part session cache where we wont need to make any change in code other than to web.config file.
We so many article around it has created confusion.
I would appreciate best way we can migrate to azure hosting without making changes to code other than web.config file.
I looked at Azure Redis Cache but this also required to install Microsoft ASP.NET Universal Providers and changes to config file link.
Does Azure provide MS SQL Database with build in support for SQL Session, so that we only need to make change to web.config file rather than installing packages using nuget etc..
This option of Microsoft blog seems to be the option can some config if this right & easy approach. but also at the comment user have posted few issue with this approach
https://blogs.msdn.microsoft.com/sqlserverstorageengine/2017/11/28/asp-net-session-state-with-sql-server-in-memory-oltp/
Based on above let me give more details
We use windows based dedicated server for hosting
We use MS SQL SERVER Windows 2012 for database
IIS 7.5
and other software to managing website such as plesk
We have website developed in asp.net webform based website running with framework 4.0 or 4.5
We also have few asp.net MVC based website running on framework 4.5
We use InProc default session state
Firstly, my big concerns are session state, i want to migrate to Azure without making any changes to code except changes to web.config is this possible?
Second we use MS SQL SERVER 2012 as database what is equivalent of same in Azure as in some page it refers database as SQL Database and some where as Azure SQL Database which creates confusion of this SQL Database or Azure database as i have red that these are two different things?
Third, let us say i choose Meb+Mobile--> App Service Standard Package (which comes with upto 10 instance) what are these instance? and will individual session always connect to same instance?
Forth: Database i have about 20 database one of them is about 6GB & other database are about 200MB-700MB which service should i use for database
Single Database or Elastic?
Can i create multiple database under elastic mode?
Let us say if i choose "100 eDTUs: 10 GB included storage per pool, 200 DBs per pool, $0.20/hour" will i have total of 10GB space for all database in elastic pool and what is per pool and how many pools will i get in this option.
Fith:Disk Space, let us say i choose App Service "S2: 2 Cores(s), 3.5 GB RAM, 50 GB Storage, $0.200", is 50GB diskspace include OS or space allowcated to file which we upload?
I have asked too many question as i didnt had clarity from MS chat as they just passed links which can be confusing at time
Yeah, the Redis session state provider is a Nuget package, though you could possibly install it in another project and just throw the DLL in the app's bin folder. I have not tested this, so I can't know if it would actually work.
But another option for legacy apps is to keep ARR Affinity on in the App Service (if you are using them). This effectively sets a cookie on the client when they first connect so the load balancer will always connect them to the same instance, so in-memory session state works.
The problem with that is of course if the instance restarts for any reason, you lose the session state. Auto-scaling is also a bit of a problem.
I'm upgrading an ASP.NET 4.0 app from:
Windows Server 2003 and IIS 6
to:
Windows Server 2008 and IIS 7.5
This app is based on ASP.NET Web Forms and not MVC. I currently use SQL authentication, but I would like to follow best practices in the new environment.
Both the IIS 7.5 machine and the SQL Server 2008 machine will reside in a DMZ with its own domain controller. It would be nice if we could use similar connection strings for Dev, Test and Prod environments. What's the best practice for this situation? I've read about three options.
ApplicationPoolIdentity
Create your own service account on the domain
SQL authentication
Here are links to questions that discussed related issues, but nothing seemed to answer my specific question.
User ASP.NET Runs Under
Assign Permissions to ApplicationPoolIdentity Account
I recommend AD account for running the app pool. Then, permissions can be created at SQL server for that same account. The conn string used by the app will then not have to contain account info at all (trusted connection), and you will have one less thing to worry about related to security. As additional precaution, remove that AD account from all user groups, and don't use it for anything else but for this one thing (the app pool). Give that user read access to website files, and write access only to folders that it needs to write to (e.g. to dump log files).
As far as best practices is concerned, I don't think any of the 3 options you listed is better over the other one; all of them can do the job securely and efficiently if used correctly. Your decision should be based on which of those offers advantages to you considering your particular environment, company policies, etc., but again, none of them are bad practice.
Are there any document-databases, similar to MongoDB, that run within an ASP.NET web application, and could be hosted on a server without any unique machine configuration?
I'm asking this because the hosting provider I'm currently with only support SQL Server 2008 as a database, but I'd like to run my website off a document database.
(Or am I better off going with a specialized database host, such as MongoHQ)?
I currently use MongoDB for ASP.NET apps and it works quite well ... however we have our own servers.
The question here seems more to do with the host then MongoDB, or CouchDB, etc.
In this case, yes ... I would say a good option would be to go with a hosting service like MongoHQ (they have quite reasonable rates compared to SQL Server hosts for example.)
That said why not just get a VPS that gives you total control of you Windows server?
You can find a Window VPS for reasonable prices and install whatever you want on them ... including MongoDB.
I have a web app that I am working with on a separate server. I didn't originally create it, but I have to maintain it. I had to to do some manual editing of one of the database tables, which I did through Visual Studio 2008 installed on the same machine. Now I get SQL exceptions regarding Network Service not having the right privileges.
How do I avoid this from happening? I haven't modified any settings regarding the security or access information. It was working before I made the modification, and now it isn't.
Thanks!
Did you by chance change the connection information stored for the DB? Perhaps remove a explicit user (SQL Authentication) and replace it with a Trusted_Connection?
Also did you change the webserver to no longer use authentication?
The error sounds like it is coming from the fact that the Network Service account (the one generally responsible for running ASP.NET pages) cannot access the DB. This happens mostly when authentication is disabled, and there is no explicit SQL Authentication.
My Problem is the following,
I have an ASP.Net web site hosted on IIS. This web site connects to an Access 2007 DB file on the same server. The DB file contains links to sharepoint lists on another server on the same domain. If I run the web site on the visual studio built-in server, I can Open connection to the DB file and retrieve data just fine. But whenever I try to run the web site over the IIS, the web site can't open a connection with the DB file.
What do you think the problem is?
Thanks.
It will be a permissions problem. When you run with Visual Studio's web server it is running as you, IIS on the other hand runs (by default) as Network Service. This is limited in what it can do.
To access an access database (no pun intended) the account that IIS runs under will need the ability to read, write, execute, change and delete for the directory the database is in. By default this should be granted to the APP_DATA directory, if your access database is elsewhere you will need to grant these permissions.
Connecting via Access to a remote machine is a whole other problem, it's unlikely this will work because the Network Service account is a local account and will not exist on the sharepoint server, and you cannot grant access because it does not exist.
If you were in a domain you could run IIS under a suitable locked down domain account and it might work, but frankly it's all a bit messy!
Have a look at this article:
How to connect to a remote Access database from Active Server Pages
http://support.microsoft.com/kb/253580
Yes, I know your database is on the same machine, but there are differences in permissions and authentication for files and folders when you run IIS. The chances are good that whatever is hanging you up is covered in this article.
Whether mixing Access databases and IIS is a Good Thing or not is a separate discussion...
Access 2007 makes connecting to SharePoint a breeze. After you link to a list, then ADO, and even DAO + VBA code and your sql queries work on those lists!
I seen a good number of people thus start using the JET (actually it called ACE in access 2007) as a data connector to SharePoint for this very reason. Since your are building a web based system then we not using ms-access here, but ONLY using the 2007 version of the JET data engine that ships with access 2007.
Someone does need to come out with a OLEDB provider for SharePoint lists that allows ones web site or .net code to view those lists as standard sql tables like ms-access can. Using JET as the data connector system is likely not such a good idea. I do realize that you not storing nor placing data in the access JET table, but are using the wonderful ability of the new access JET engine to view and use SharePoint lists as regular sql tables. This approach does allow your ASP.net code to execute sql updates on that data or do whatever as if this was a regular sql table. It does make this oh so easy.
The security permissions on the SharePoint site are thus going to view this connection as not as a end user, but always see the USER as the actual web site connecting (or at least the user you were in ms-access when you linked the table to SharePoint). I don’t believe the SharePoint user authentication process can work reliable when you do this. What will happen is you change a few things on the SharePoint site, and next thing you know the JET connection will be trying to prompt you for new logon credentials. You can’t provide nor control those logon credentials at that point in time.
So, as others pointed out, this is going to be problematic and not reliable.
Using Access as a fudge to access SharePoint from an ASP.net site is going to give you lots of pain in the long run.
A much better way would be to use SharePoint's web services to access that data - removing Access from the equation altogether.
http://www.scribd.com/doc/8634090/Accessing-SharePoint-Data-Using-C-Without-Running-Code-On-the-SharePoint-Server-Part-1
MSDN - Using ASP.NET web services
Creating and Consuming a Web Service