Multi-tenant applications with elastic database tools and row-level security

SafeValue must use [property]=binding: Today, among cloud computing, the software as a service or SaaS became one of the most popular. In this distribution model, the provider places client applications and makes them available to them over the Internet. SaaS is one of the main three types of cloud - along with infrastructure as a service (IaaS) and platform as a service (PaaS). Due to its easy access, software as a service has become a standard delivery model for many business applications and part of the strategies for software delivery providers for companies. The SaaS model provides access to many business applications - mail and collaboration software, a customer information management system, accounting information processing, personnel and sales management, financial and database management, content, and document editing. (see http://g.co/ng/security#xss)

SafeValue must use [property]=binding: To provide the implementation of the SaaS model, we are using the Azure SQL Database. In turn, the Azure SQL Database has terrific tools to enable scaling the data tier of a multi-tenant application - Elastic database tools and row-level security (RLS). The multi-tenant application is that kind of app that allows us to serve multiple customers with one install of the use. Thus, the cooperation of these technologies helps us build an application that has a highly scalable data tier. What exactly does each of them? (see http://g.co/ng/security#xss)

SafeValue must use [property]=binding:

• Elastic database tools are responsible for the ability to scale out the data tier with standard sharding practices. For this purpose, it uses .NET libraries and Azure service templates. At the same time, many of the infrastructural tasks typically associated with sharding become automate and streamline easily by managing shards using the Elastic Database Client Library.
• Row-level security is on guard to safely store data. Each of the multiple tenants may count on it in the same database. It's achieved by RLS security policies that filter out rows that do not belong to the tenant executing a query.

Thereby an application is able to store data for multiple tenants in the same shared database. And this is really good because we can save a lot per tenant when the tenants share a database. Never the less we are able to share exclusive conditions for the premium tenants. Each of them can pay for their own dedicated single-tenant shard. They can get the benefit from single-tenant isolation, which provides firmer performance guarantees: there's no place for competitors in a single-tenant database. The point is that the elastic database client library data-dependent routing APIs provide the correctness of the automatic connection of each given tenant to the exact shard database. There is no other Tenant Id then right Tenant Id of the given tenant. And this Tenant Id is the sharding key which is contained in one shard. All the RLS security policies within the database tuned to keep a connection with the given tenant to only those data rows that contain its Tenant Id. This ensures a high level of security in multi-tenant applications applied in the Azure SQL Database. (see http://g.co/ng/security#xss)