Как вы вкладываете аутентификацию, роли и безопасность в свой DDD? - PullRequest
Новая
       17

Как вы вкладываете аутентификацию, роли и безопасность в свой DDD?

11 голосов
/ 21 мая 2009

Как вы реализуете роли и безопасность в своих проектах C # Domain Driven Design? У нас возникают споры о том, должно ли оно быть реализовано вызывающим приложением (ASP.NET MVC) или в самой доменной модели (модели объектов и сервисов). Некоторые утверждают, что это должно быть на самом веб-сайте, поскольку там уже существует аутентификация. Но это означает, что вам придется заново внедрять систему безопасности каждый раз, когда вы интегрируетесь с основными бизнес-системами.

В качестве примера: Администратор должен иметь возможность выполнять практически любые действия в системе, такие как редактирование и удаление записей (т. Е. Они могут удалять заказ пользователя). Пользователь, с другой стороны, должен иметь возможность редактировать и удалять только свои собственные записи (то есть он может добавлять / удалять товары из своей корзины).

Кстати, вот хороший тезис на тему, который охватывает 7 различных сценариев, касающихся DDD & Security:

Безопасность в доменном дизайне

  • Глава 4 Сценарии проектирования службы безопасности
    • 4.1 Сценарий 1: Служба безопасности как обычная услуга
    • 4.2 Сценарий 2. Безопасность, встроенная в пользовательский интерфейс
    • 4.3 Сценарий 3: Служба безопасности, инкапсулирующая модель домена
    • 4.4 Сценарий 4. Служба безопасности в качестве шлюза для пользовательского интерфейса
    • 4.5 Сценарий 5: служба безопасности как адаптер для пользовательского интерфейса
    • 4.6 Сценарий 6: Служба безопасности, интегрированная AOP с адаптерами
    • 4.7 Сценарий 7: Служба безопасности, интегрированная с AOP

Лично я бы склонялся к АОП, используя PostSharp, но прежде я с этим не особо справлялся, поэтому не решаюсь сделать прыжок.

1 Ответ

7 голосов
/ 21 мая 2009

Не забывайте, что во время выполнения уже встроена абстрактная система безопасности / пользовательская система - принципал (см. Этот существующий ответ - обратите внимание, что GenericIdentity - это всего лишь один вариант; это довольно тривиально для написать свой собственный).

Ваш пользовательский интерфейс может обрабатывать создание и назначение принципала на основе конкретной реализации (действительно, IIRC ASP.NET и WCF делают это автоматически, или для winforms / wpf вы можете использовать идентификатор Windows, или (через веб-сервис) тот же логин ASP.NET).

Ваша бизнес-логика просто проверяет Thread.CurrentPrincipal; из этого вы можете получить имя, метод аутентификации и проверить роли (без необходимости знать, как реализованы роли).

Среда выполнения также предоставляет встроенные проверки: 

    [PrincipalPermission(SecurityAction.Demand, Role = Roles.Admin)]
    public void Foo() {...}

(где Roles.Admin - строковая константа имени вашей роли). Это автоматически проверит доступ, выдав SecurityException, если не в роли. Вы также можете проверить с помощью кода (полезно, если роль не зафиксирована во время компиляции).

Очевидно, что ваш пользовательский интерфейс должен проверять роли (чтобы отключить / скрыть функциональность), но хорошо иметь бизнес-код , обеспечивающий роли, без необходимости знать о пользовательском интерфейсе.

* * Тысяча двадцать-одина (добавлено) * * 1 022

Следует отметить, что GenericIdentity удобен для юнит-тестов. Конечно, вы могли бы использовать свой собственный API безопасности, и никто не остановит вас ...

...