We have an iOS app where users can register, login, and generally do user-specific stuff. We are currently hosting it in Azure SQL DB and using other Azure Services such as Web Applications, Azure Functions etc.
If we want to scale the app for different Countries, we are aware that there are different data privacy concerns per Country. As such, should we be creating different Azure Environments for each country? And develop different versions of the iOS app to point to the specific Azure Environment to use?
Is this is the correct practice? Or is there a recommended pattern / approach for this?
Thank you!
It really depends on the requirement and the end customer, in some cases certain countries have common policies in place.
You can read and understand the best practices and Guidance for Data Controllers when you are migrating/implementing applications on azure
Related
Recently, I want to use openLDAP to build a large web server by using multiple small servers and I expect that it can support many users to use the services of the website. Is it possible to do it? Is there any other better solution to do the same thing? RADIUS?
A single LDAP server will probably hold as many users as your WEB server could handle. You would of course use the LDAP best practices of always having more than one server to meet your specific availability requirements.
Depending on your design requirements, you might want to consider some of the "Cloud" services for user store and Authentication.
LDAP implementations are more flexible than Radius and often in large Radius implementations Radius servers are simple a access protocol with the users being stored in LDAP.
Background:
Our team is building an inhouse Intranet web application. We are using a standard three layer approach. Presentation layer (mvc web app), Business layer and data access layer.
Sql database is used for persistence.
Web app / iis handles user authentication (windows authentication). Logging is done in business and data access layer.
Question service account vs user specific Sql accounts:
Use service / app account:
Dev team is proposing to set up service account (set up for application only). This service account needs write & read access to db.
Vs
Pass on user credentials to SQL
IT ops is saying that using a service account (specifically created for app only) for db access is not deemed best practice. Set up Kerberos delegation configured from the web server to the SQL server so that you can pass on the Windows credentials of the end users & create a database role that grants the appropriate data access levels for end users
What is the best practice for setting up accounts in sql where all request to db will come through the front end client (ie via bus layer and then data layer)
The Best Practice here is to let the person/team responsible for the database make the decision. It sounds like the dev team wants to forward (or impersonate) some credentials to the DB which I know that some small teams like doing, but yes that can leave things a bit too open. The app can do whatever it likes to the database, which is not much of a separation if you're into that kind of thing.
Personally, if I understand what you're saying above, I do more of what the IT team is thinking about (I use Postgres). In other words my app deploys over SSH using a given account (let's say it's the AppName account). That means I need to have my SSH keys lined up for secure deployment (using a PEM or known_keys or whatever).
In the home root for AppName I have a file called .pgpass which has pretty specific security on it (0600). This means that my AppName account will use local security to get in rather than a username/password.
I do this because otherwise I'd need to store that information in a file somewhere - and those things get treated poorly pushed to github, for instance.
Ultimately, think 5 years from now and what your project and team will look like. Be optimistic - maybe it will be a smashing success! What will maintenance look like? What kinds of mistakes will your team make? Flexibility now is nice, but make sure that whomever will get in trouble if your database has a security problem is the one who gets to make the decision.
The best practice is to have individual accounts. This allows you to use database facilities for identifying who is accessing the database.
This is particularly important if the data is being modified. You can log who is modifying what data -- generally a hard-core requirement in any system where users have this ability.
You may find that, for some reason, you do not want to use your database's built-in authentication mechanisms. In that case, you are probably going to build a layer on top of the database, replicating much of the built-in functionality. There are situations where this might be necessary. In general, this would be a dangerous approach (the database security mechanisms probably undergo much more testing than bespoke code).
Finally, if you are building an in-house application with just a handful of users who have read-only access to the database, it might be simpler to have only a single login account. Normally, you would still like to know who is doing what, but for simplicity, you might forego that functionality. However, knowing who is doing what is usually very useful knowledge for maintaining and enhancing the application.
I have a website that I've built (hosted on Amazon S3) and it works great. The only problem is that all of the data is static. I'd like to create a SQL database in the cloud that would allow me to store basic text data from users after they submit forms. I'm still a novice web-developer but I've used sqlite3 for several of my Java desktop apps and I'd like to use that SQL knowledge to create this online database. I guess what i'm asking (in my ignorance) is: how can I create a sqlite-type database that is stored in the cloud and that I can query against using javascript?
Where do I get started? Is there a service like Amazon AWS or Azure or something where I can create this database and then use some sort of jQuery/Javascript API to query data from it? I don't need a ton of storage space and my queries would be very basic SQL type stuff.
Any help would be greatly appreciated. Thanks in advance.
For more flexibility, less service lock-in, and cheaper scalability: I would suggest CouchDB (though you would likely still use a hosting service like Cloudant). CouchDB can host your website, and provides a HTTP API for storing data, to which your client-side JavaScript can make REST calls.
StackMob has a free package that you can use. You can use the JS SDK to write your HTML5 app and save stuff to the StackMob DB. You can host your HTML5 on StackMob for free and point your own domain to it as well. There is also S3 integration.
Some references:
JS SDK
JS SDK Tutorial
Hosting your HTML5
Custom Domains
Create a Postgres database on Heroku for free.
https://devcenter.heroku.com/articles/heroku-postgres-plans#hobby-tier
As you mentioned your website is hosted on Amazon S3 I am sure it is a static website with lots of JavaScript embedded HTML files. Due to having a static website, I can understand your requirement to use a database which can be connected from your static site and to be very honest there are not a lot options you have. Static website are considered to have no dependency on database so honestly you have very limited choice because what you are looking for is "A Database which is accessible over HTTP which you can call from scripting language withing HTML"
If you have ability to write back to S3 directly from your JavaScript code you can create a JavaScript based database within your static site which is complex but consider a choice.
In my thinking you are better off to have an extra-small instance in Windows Azure (or your choice of cloud service) and connect with a cloud based database which will be comparative cheaper and fit for your requirement.
Or unless Amazon can come up with a DB accessible from status content as S3, you really have no great choices here.
Since you are already familiar some of AWS's offerings, you should check out:
Amazon RDS - Managed Relational Database Service for MySQL or Oracle
Amazon DynamoDB - Fast, Predictable, Highly-scalable NoSQL data store
But to do what you are asking (access data via JavaScript), check out www.stackmob.com. You can host an HTML5 application with data access via backbone (javascript based framework) on StackMob.
Create a Virtual Private Server on Vultr.com. It's not the easiest way, but it's the best way for you to learn about Database Security, and it will be significantly cheaper than the other solutions, should your server begin to require more storage.
[vitrobridgedb] is free for hobby applications and pretty straight-forward to use
SQLite isn't really a good choice for web facing applications due to its scaling issues.
Both AWS and Azure support SQL databases. They also each support alternatives like MongoDB and Redis. For something as basic as you describe the only real difference is cost.
I'm new to Azure platform and pricing. I want to build a small mobile application targeting various mobile OS platforms.
Is it wise to get a SQL Azure or host my WCF service somewhere else based on the pricing?
If you recommend SQL Azure is the Pay-As-You-Go well enough to handle the app?
SQL Server vs SQL Azure
To be honest your question is quite vague, and I dont think there is an absolute right answer based on the information you have given. Your going to need to assess your requirements with the database offerings and decide what you need.
If things like load balancing, transparent failover and other cloud features pique your interest- Azure may be the correct choice. Otherwise SQL Server or other 'traditional/non-cloud' SQL DB implementations may be the way to go.
In terms of cost, here are a couple of comparisons, but again it comes down to your application specifics.
we have several sites for several different clients, each with several different databases.
Some of the databases are at client location, some are on our site.
I have been tasked with creating a few sharepoint sites that will display information from the databases.
Is it okay to call stored procedures from my sharepoint sites? Since the database is not for the sharepoint site, I feel like that site should not have direct access to the DB and should get the data through web services. Certainly, this would be the case if the data were exposed to another company, but since we are responsible for all of it, is that okay?
In my opinion you save yourself from lot of trouble by just going directly to the database, since you control both ends. The direct access to DB will also have better performance than writing some web services in between the two systems.
If the other system wouldn't be yours, I'd definitely hope that it had a web services (or RESTful web services) interface. My reasoning here is that in most software, web services are really actually meant for integrations and thus changes to them are kept at minimum. Database schema changes are fairly typical during the lifetime of a software product and thus it's not generally easy to evolve the schema if other people build integrations directly against the DB.
Querying the database directly is not a supported scenario, thus you shouldn't ever need to do that.
Best practice is to use the existing Web Services, or implement your own custom Web Service.