Schemas separados en una arquitectura multitenant

Realicé una serie de pruebas para evaluar una arquitectura multitenant usando schemas separados (un schema por cada tenant). 

La idea general fue crear una clase de acceso a datos transparente que permita que cada usuario acceda solo a sus datos. De esta manera se simplifica el acceso a datos (una única clase para todos los tenants) y se asegura un esquema de seguridad.

Para ello, primero preparé una base de datos de prueba y tres schemas diferentes:

- SchemaApp: schema para las tablas del sistema compartidas por todos los tenants, por ej., usuarios, parámetros, datos de los tenants, etc.

- SchemaA y SchemaB: schemas que simulan los 2 tenants del sistema (TenantA y TenantB)

Luego agregué a cada schema sus respectivas tablas y stored procedures

Por último cree 3 logins (AppUser, TenantA, TenantB) para los accesos a la base de datos:

- AppUser: schema por default: SchemaApp

- TenantA y TenantB: schemas por default, SchemaA y SchemaB respectivamente

AppUser tiene acceso solo a su schema, y TenantA y TenantB (además de acceder a su schema) tienen acceso a AppSchema.

Una vez lista la base de datos, schemas, tablas, stored procedures, permisos, etc realicé la clase de acceso a datos:

- para acceder a los datos comunes de todos los tenants se usa el AppUser

- para acceder a los datos privados de cada tenant se usa el usuario respectivo

Esto permitió mostrar solo los datos de cada tenant (sin realizar modificaciones en el código de la clase de acceso a datos)

Software Libre vs Software Propietario

Dejo este post de otro blog que me pareció interesante y objetivo: http://gustavoazcona.blogspot.com/2009/03/software-libre-vs-software-propietario.html

Libro ASP.Net MVC 1.0

Dejo el link al blog de Scott Guthrie que se refiere a la versión Html del libro sobre la última versión de MVC

http://weblogs.asp.net/scottgu/archive/2009/04/28/free-asp-net-mvc-nerddinner-tutorial-now-in-html.aspx

Uso de Schemas en SQL Server 2005

En SQL Server 2005 cada esquema es un espacio de nombres distinto que existe de forma independientemente del usuario de base de datos que lo creó. Es decir, un esquema simplemente es un contenedor de objetos (vistas, tablas, stored procedures, etc).

Algunas características importantes de los schemas son:

• La propiedad de los esquemas y de los elementos que se pueden proteger (con ámbito de esquema es transferible): ALTER AUTHORIZATION (Transact-SQL).
• Es posible mover objetos entre esquemas: ALTER SCHEMA (Transact-SQL).
• Un mismo esquema puede contener objetos que sean propiedad de varios usuarios de base de datos.
  Varios usuarios de base de datos pueden compartir un mismo esquema predeterminado.
• Se pueden administrar los permisos sobre esquemas y sobre elementos que se pueden proteger con mayor precisión que en las versiones anteriores: GRANT (permisos de esquema de Transact-SQL) y GRANT (permisos de objeto de Transact-SQL).
• Cualquier entidad de seguridad de base de datos puede ser propietaria de un esquema. Esto incluye funciones y funciones de aplicación.
• Es posible eliminar un usuario de base de datos sin necesidad de eliminar objetos en un esquema correspondiente.
• El código escrito para las versiones anteriores de SQL Server puede producir resultados incorrectos si el código considera que los esquemas son equivalentes a los usuarios de base de datos.
• Las vistas de catálogo diseñadas para las versiones anteriores de SQL Server pueden producir resultados incorrectos. Esto incluye a sysobjects.

Realicé un par de pruebas referidas al uso de Schemas en una aplicación multitenant.

1 - Crear el inicio de sesión
2 - Crear el usuario de la base de datos
3 - Crear el schema en la base de datos
4 - Asignar el usuario creado al schema
5 - Asignar permisos a nivel de schema
6 - Las tablas/procedimientos que se agreguen al schema van a tener esos permisos

Notas:
- Los SP y Tablas tienen que estar dentro de cada schema para facilitar la seguridad

Create Table Schema1.Tabla1 ( Texto Varchar(10) )

Insert Into Schema1.Tabla1 Values ( 'Prueba' )

Create Procedure Schema1.usp2

- Si el usuario tiene como default un schema, entonces los SP no se tienen que ejecutar con el nombre de ese schema

Exec usp1 (el Usuario tiene como default Schema1 => el motor de base de datos busca usp1 dentro de ese schema. Si no lo encuentra busca dentro del schema dbo y sino da error)

- Dentro de los SP no hace falta usar el schema de la tabla: Esto permite que el mismo script se pueda recompilar en cada schema si tener que cambiar las intrucciones

Create Procedure Schema1.usp2

As

Select * From Tabla1 --> Accede a Schema1.Tabla1

Create Procedure Schema2.usp2

As

Select * From Tabla1 --> Accede a Schema2.Tabla1