Коя е най-добрата практика за управление на сигурността на Multitenant в Breeze?

Разработвам приложение на Azure, използвайки този стек:

(Клиент) Angular/Breeze

(Сървър) Web API/Breeze Server/Entity Framework/SQL Server

С всяка заявка искам да се уверя, че потребителят действително има разрешение да изпълни това действие с помощта на код от страна на сървъра. Въпросът ми е как най-добре да внедря това в контекста на Breeze/Web API.

Е най-добрата стратегия за:

  1. Да промените контролера на Web API и да опитате да анализирате съдържанието на заявката Breeze, преди да я прехвърлите по-надолу по веригата?

  2. Да промените EFContextProvider и да добавите тест за оторизация към всеки изложен метод?

  3. Преместете цялата защита в слоя база данни и се уверете, че User GUID и Tenant GUID са задължителни параметри за всяка заявка и връщат само подходящи данни?

  4. Някакво друго решение или комбинация от горните?


azure entity-framework asp.net-web-api breeze dotnetopenauth
person Graham    schedule 12.10.2013    source източник

Отговори (1)


arrow_upward
1
arrow_downward

Ако използвате Sql Azure, тогава една опция е да използвате Azure Federation, за да направите точно това.

Казано много опростено, ако имате TenantId във вашата таблица, която съхранява данни от множество наематели, тогава преди да изпълните заявка като SELECT Col1 FROM Table1, изпълнявате USE FEDERATION... оператор, за да ограничите резултатите от заявката само до определен TenantId и не е необходимо да добавяте WHERE TenantId=@TenantId към вашата заявка,

Пример за ИЗПОЛЗВАНЕ НА ФЕДЕРАЦИЯ: http://msdn.microsoft.com/en-us/library/windowsazure/hh597471.aspx

Имайте предвид, че използването на Sql Azure Federation идва с много прикачени низове, когато става въпрос за изграждане на DB схема, един от най-добрите блогове, които съм намерил за това, е http://blogs.msdn.com/b/cbiyikoglu/archive/2011/04/16/schema-constraints-to-consider-with-federations-in-sql-azure.aspx.

person pateketu    schedule 13.10.2013
comment
Поразен от този (в добрия смисъл). Това изглежда страхотно, но докато чета, чакам някаква грешка като трябва да използвам Azure Access Control Services или работи само с Azure Active Directory! - person Graham; 15.10.2013
comment
Няма подобни неща! просто определено внимание в DB Schema. Основно 1) Всяка обединена таблица трябва да има TenantId и трябва да е част от Parimary key 2) Без колони за ИДЕНТИЧНОСТ 3) Без JOINS с таблица в основната DB 3) Таблицата с референтни данни трябва да живее във всяка федерация, има няколко други, които сте прочели На. Нашето приложение е с малък размер в момента и се нуждае само от една федерация, ние използваме абсолютно същата схема за облачна версия и локална версия на приложението. - person pateketu; 15.10.2013