Getting to Know Azure Mobile App Cont.

Microsoft Azure Mobile App has recently gone GA (General Availability) and has definitely captured my attention. Mobile App is a tremendous accelerator that enables us to go from an idea to a functional prototype quickly. Then, we can continue to build on that initial investment to create a robust production ready app. Finally, this post is all about using Visual Studio Team Services (VSTS) to build and publish apps to HockeyApp, so that we can test and assess quality before our apps make it to our favorite app Stores.

Refreshing Authentication Tokens

Authentication Tokens are short-lived and having users login to the App frequently can cause friction. This is definitely undesirable and can be dealt with by identifying when a Token is no longer valid. When this condition is met, we can attempt to refresh the Authentication Token by calling the Azure App Service Token Store APIs.

Using Azure PowerShell 1.0 & ARM

Recently the Azure team released a new version of Microsoft Azure PowerShell. They finally broke through v1.0, and that comes with a few breaking changes. But don’t worry, it’s for the best!

This blog post is all about deploying a Windows 10 Visual Studio Virtual Machine to a secured Virtual Network on Microsoft Azure.

Deploying an ARM Template Using PowerShell

Why are Virtual Networks Important?

As a developer, I used to forget about Virtual Networks. And to be fair, I shied away from pretty much everything that can be considered as infrastructure.

Microsoft Azure is a game changer! It requires Developers and IT Pros to collaborate on projects. Let’s take a moment to set things right. Developers and IT Pros are not competing against each other in this new world. They collaborate in order to produce value for the business and customers.

As we move to a Cloud First and Mobile First world, security is more important than it ever was. On Microsoft Azure, the first step towards securing your application resources is to create a Virtual Network.

The Challenge

As developers, we are up against odds that push us to make trade-offs in order to go into production on time. More often than not, it’s a race where security becomes an afterthought.

Securing Azure SQL Databases

Security mechanisms come in many flavors. It is a requirement that needs to be defined and implemented on day 1. These rituals (policies and practices), must become natural in your application life cycle management. Consider these as a starting point from which you can develop your own security practices.

• Do not use the default user for development, testing or for deployments
  • Create a user specifically for deployments (can perform schema alterations)
  • Create a user on a per application basis (cannot alter schema and has limited write access)
  • Create a user for support investigations (this should be read-only)
  • Create individual accounts for members of DevOps who will need to act upon the database. (these accounts should have limited write access)
• Reference data should be read-only (immutable versions) and should only be updated through deployments. This type of data can be stored in NoSQL data services to augment the overall scalability of your application.
• Enable Auditing for Azure SQL Database, this feature will give you deep insight in how the database is manipulated and about how it is used.
• Use SQL Database Projects to design, build, version and deploy
• Use schemas to segregate tenants, reference data, activity data and resouce (shared) data.
• Use schemas to keep track of ownership chaining
• Encrypt connection string passwords at rest
• Use strong passwords
• Set Trusted_Connection=False in the connection string. This forces server certificate validation
• Set Encrypt=True in the connection string to force the client to use SSL
• Ensure that you are covered against SQL Injection
• SQL Database Firewall rules should block everything except the consuming applications
  • SQL Database Firewall rules should be set on both the Server and Database