How fetch data from Azure SQL via Xamarin App? Tutorial - sql-server

I am creating simple application where I need get and fetch data to DB. As I find out from Xamarin app is standard using of HTTP request to DB instead of directly connect to DB.
I create Azure SQL DB, I create application with connection to this DB. But I cant really find out how it now should works.
There is no many tutorials or they are not fully described.
I read this one https://learn.microsoft.com/en-us/azure/app-service-mobile/app-service-mobile-xamarin-forms-get-started#download-and-run-the-xamarinforms-solution
I find many references on this one but it seems out of date. Everybody recommended download the project from section
Run the Xamarin.Forms solution
On the settings blade for your Mobile App, click Quickstart (under Deployment) > Xamarin.Forms. Under step 3, click Create a new app if it's not already selected. Next click the Download button.
Under this tab I have only references to next tutorials but not any to Project Download. (screenshot below)
https://imgur.com/THCdUE1
Can you give me some advice if I do something wrong? Or link to updated tutorials? I am little desperate from this
Many Thanks

Azure SQL is not an HTTP/s service-- it runs proprietary SQL Server protocol on port 1433, just like on-premise versions of SQL Server.
If you are trying to connect directly to SQL Server from a Xamarin App, you are almost certainly making a mistake. Doing so would require providing credentials to your Xamarin app that can connect directly to your database, which opens your database up for a malicious user to do pretty much whatever they want to. The reason this kind of 2-tier application is dangerous is because the Xamarin app runs on an untrusted device (your user's mobile device), and a malicious user can intercept any data that your application has in memory, including your database credentials. They can then use those credentials to gain access to your database. Unless you were to use unique database credentials for each user (very impractical) and setup very stringent security roles in SQL Server, it'd be impossible to keep a malicious user from accessing the database for all of your other users (which is very, very bad). The other problem is that many networks block traffic on port 1433, or only allow access via an HTTPS proxy server, so your application would not function on many networks if it tried to connect directly to SQL.
This is the answer to your question, but please don't do this:
If you are certain that you have taken care of the security correctly, you should be able to install the System.Data.SqlClient nuget package and use that to communicate with SQL Server as you would with any .NET application. Here's a code example from Microsoft.
This is my opinion on what you should do instead:
The correct way for most Xamarin applications to communicate with Azure SQL database would be via an intermediary application server.
If your application access data specific to a user, should have per-user credentials in it (username and password that get exchanged for an authorization token when the user logs in is a common technique). The Xamarin app would then use HTTPS to make requests to your application server using those user credentials. The application server would validate the user credentials (authenticate that they are legitimate and authorize the data being requested based on who the user is) and make requests to Azure SQL.
If your application only access public data anonymously, then you can make unauthenticated requests to your application server which will blindly request that data from Azure SQL and return it to your client (though it would also return the same data to any attacker on the internet, so be sure if you use this approach you intend all data served to be public to the world).
In both cases, your application server would be the only piece that communicates with Azure SQL. For a .NET application this would typically be done via System.Data.SqlClient or perhaps indirectly through an ORM like Entity Framreworks. The advantage to this 3-tier approach is that the untrusted client tier does not have unrestricted access to your database tier. Only the middle application server tier has the credentials for SQL Server, and it is trusted and runs in a secure environment (a server you manage, not an end-user's mobile device). This means that an attacker cannot intercept the database credentials and misuse them. It also means that your application only requires HTTPS data access to function, so your application will work on almost any network.
This is probably not the answer you are looking for, since it involves authoring an entire application server that has to be hosted by you (Azure App Service would be my recommendation, if you are already using Azure SQL). It also requires you to implement an API on the server, and then write an API client for your Xamarin application. This is no small amount of work.

Related

How to ensure an app builder doesn't have acccess to database?

So, we have made a web application login protocol via which users can query a database on Azure SQL Server with sensitive data. Now partner-organizations want to use the same app to query their own databases on their own Azure SQL Server.
Is there a way where we can ensure that as admin + host of the web application we don't have access to their sensitive data, while we are able to send user from the correct Identity Provider through.
Until so far I found the OAuth 2.0 Token Introspection, specifically this implementation: https://wiki.surfnet.nl/pages/viewpage.action?pageId=23794471. Is there a way to implement this within Azure around the Azure SQL Server (if needed via a very simple API)?
Azure built-in reader role:
View all resources, but does not allow you to make any changes.
EDIT: If the problem is security you need to solve it through security countermeasure like Always Encrypted:
This provides a separation between those who own the data and can view
it, and those who manage the data but should have no access -
on-premises database administrators, cloud database operators, or
other high-privileged unauthorized users.

Do I need to register my SSL certificate in IIS and SQL Server?

I have purchased an SSL certificate and installed it using IIS on my remote system. So I can therefore access my remote system using https://myremotesite.co.uk. All is fine, it seems to work; users can register and login to my remote site and download my GUI to run my application which stores and retrieves data from my SQL Server database.
When a user runs my GUI to access my application it prompts them for their login-id and password and, if they are authenticated, my application pops up on their screen. All is well, it all seems to work fine.
However, I have read that access to the SQL Server database itself can be restricted with an SSL certificate and to do this I would need "Encrypt=yes" in the connection string which my GUI uses to check authentication.
Is it necessary for me to do this? Or is safe to just rely on the IIS HTTPS service? So my question is ... do I need to register my SSL certificate with BOTH IIS AND SQL Server or just ONE of them, and if so, which ONE?
Thanks for the answers thus far .. to explain further, the GUI connects to an IIS controlled website which has specific handlers written to perform a restricted set of database queries. So my database DOES reside on my server, but it only allows my server's (local) IIS to 'login' and insert, update and extract data.
Once the IIS website service has extracted data, it then returns the same to the GUI. So the GUI has no DIRECT access to the database. What I am concerned about is if - by some malicious means - the database was copied in its entirety ... could/should I use my SSL certificate to encrypt sensitive data in this event?

Is it possible to use windows authentication in SQL Server database in 3-tier architecture with WebAPI service?

We currently have a two-tier enterprise application where a Windows desktop app connects directly to an SQL Server database. Data access permissions are set in the database using standard SQL Server features, sqlserver windows authentication is being used (users use their domain logins).
We would like to introduce an application server layer, but we need the same authentication scenario, i.e. all the queries, initiated by the desktop app, have to be run in the database under user domain account that started the app.
It is also important that users do not enter their credentials in the app, the current domain account is used.
Client application is a WPF .NET desktop app.
Is this possible using ASP.NET WebAPI as an application server?
If you're using Active Directory to authenticate users, once they've successfully authenticated into your application, you will have their domain identity. You could then pass that as a part of the connection string for every user-specific database CRUD operation.
I would recommend that you have a shared SQL login though for core things such as caching, database logging and auditing, error logging, application authentication and authorization, etc.

EF Code First how correctly set up database credentials

I have developer MVC4 + EF Code First + SQL Server 2008 web app. Uploaded it to prod server with IIS7. Created new credentials PC. Added empty database PCDB to SQL Server and assigned user PC to it with owner permission. When I run web app I get error
Model compatibility cannot be checked because the database does not contain model metadata. Model compatibility can only be checked for databases created using Code First or Code First Migrations
My connection string is
data source=174.xx.x.x;initial catalog=pcdb;user id=pc;password=xxxxx;
The exception is understandable, I can delete PCDB database and let EFCode First create it by itself. But how about credentials PC? I do not want to make PC user as administrator but without it EF Code First will not be able to create new database in SQL Server.
How to solve the problem?
The overall design starts with Forms or Windows authentication at the WebsiteASP.NET/ IIS.
and ends with Application and DB authentication you want/need. Application authorization is another topic. I will not discuss that here.
You dont actually state the authentication model desired.
So I will start with a disclaimer. This a suggestion that I WOULD use in a production site. But it is not the ultimate end game nor is it the ONLY short term solution you might consider.
This is a solution that a one man show can get working. And is secure and without excessive admin effort to keep running.
Use SQL server logon via Windows Auth
BUT you do not need to add every user to SQL server.
There is also the option of impersonation. But that can get tricky and this explanation is not NOT impersonation. That is another another approach.
first make sure Website is using Windows Authentication
set IIS to use Windows Authentication:
Now the APP Pool behind the website on IIS you have configured. .
Im going to suggest a Psuedo-service user in the APP pool as a good way to start.
ie WEBAPPLICATION_X_USER. You can have a separate user per APP pool. Each user can access only its DB. So you get application separation. Your enter a user and password here. IIS will encrypt and decrypt as required. (better than plan text in Web.config)
This user should have reduced auth on the server itself. NOT AN ADMIN user on domain or even local admin. Just enough so it can use Sql server to create a DB. So create a regular windows user
Let ASP.Net logon to DB. Let ASP.net encrypt and decrypt the password.
So now the situation is Windows AUTH on IIS. IIS has an App pool with a special windows user that can logon to SQL server. You have added this user to SQL server instance and Allocated this service user the ability create DBs. Dont give the user access to ALL Dbs :-) Just the one it will create. Plus public access (via EF).
Verify the user credential situation in your WEB APP.
See [System.Security.Principal.WindowsIdentity]
This should show your windows authenticated end user.
System.Environment.UserName should have the service user ID you placed in the IIS APP POOL.
Now when EF goes to create or access data on the SQL server instance, it will connect with
System.Environment.UserName if the WEB.CONFIG entry is set to use windows integrated security
<connectionStrings>
<add name="DbContextName" connectionString="Data Source=Your SQL server Instance;Initial Catalog=The DBNAME;Integrated Security=True;MultipleActiveResultSets=True;App=EntityFramework" providerName="System.Data.SqlClient" />
And you KNOW the authenticated user.
httpContext will give it to you as does thread current principal.
HttpContext.User is by default mapped to {System.Security.Principal.WindowsPrincipal}
So you can perform application level checking.
The same approach should also work with Forms Authentication.
WARNING: If you have windows WPF approach (ie you are not using IIS and therefore no APP pool), then this approach MUST be changed and is more complex and no longer the best place to start.
I hope this helps you get started

Which method of Authentication is correct for Sync Framework client application (database synchronization)?

Users will be out in the field collecting data on windows client app in areas with poor internet connection. Days or even weeks at a time away from any network connection. The lucky ones will bring their laptop back to a regional office to sync the data they've collected when they login to the company network. Others will have to resort to plugging into a client/customer internet connection and/or Internet Cafe connection to perform the data sync.
The app stores the data on a local sql server 2008 R2 express database and the client will initiate a database sync to the SQL Server 2008 standard in HQ as and when connection is available.
User Authentication and role based security are requirements of the App. Which method should I be using: Forms Authentication or Windows Authentication ? (And I think I've come across a 3rd type called Custom Authentication ?)
Sorry, I'm really lost on the authentication stuff - first time doing it and not sure of the pros & cons of each type. Can anyone advise which I should be using for this scenario ?
UPDATE: I've actually got the synchronization working now using the SQL Server's external ip address in the connection string and SQL Authentication for the user logins. Would this be an accepted practice or am I violating any security principles?
I still have to get to the role based security piece - can role based security work with SQL Authentication?
Also, new wrinkle: turns out that some of the remote users once they have been issued their laptop from Head Office may never login to the organisation's Domain again so their Login's Trust relationship with the domain expires after a few months. Therefore, I guess Windows Authentication is not viable anyway...
How will you connect to the HQ db server?
Imo the safest solution would be to sync over WCF (sample with SqlCompact to Sql Server over WCF with N-tier here). You can then implement whatever authentication scheme you want depending on the kind of security (transport and/or message) you implement in WCF. See this and this for more info.

Resources