Ограничение доступа к записям. Основанные на требовании полномочия хорошая идея
в платформе идентификационных данных .net Claim-based
Если я хотел ограничить пользователей, чтобы сделать операцию (просмотрите или редактирование) на скажем, учетной записи, конкретной учетной записи № 123456. (я говорю о предприятии, как банковский счет.) Действительно ли это - хорошая идея создать требование о каждой учетной записи, которую они могут просмотреть или отредактировать?
Какие-либо недостатки наличия большого количества требований в наборе? у системного администратора мог бы быть доступ ко всем учетным записям в системе, таким образом создающей сотни требований (возможно, больше чем один для каждой учетной записи)
1 ответ
Самым непосредственным следствием большого набора утверждений является снижение производительности, поскольку токен обменивается туда-сюда между всеми задействованными системами по сети. По умолчанию WIF, например, сериализует токен и помещает его в cookies. Таким образом, на практике вы также ограничены в количестве данных, которые вы можете хранить там. Есть и другие способы решения этой проблемы, но основная проблема сохраняется.
Второе соображение - кто и где будет управлять ассоциацией между пользователем и учетной записью. Если это специфичная для приложения вещь, то вряд ли вы будете передавать эти ассоциации центральной STS (эмитенту требований). В итоге у вас будет две STS: та, которая идентифицирует пользователей (и провайдер идентификации: IdP), и STS для конкретного приложения, которая преобразует токен, выданный IdP, в нечто понятное приложению (включая список учетных записей для конкретного пользователя)
Учитывая это, может оказаться, что ассоциация между пользователем и его учетными записями является чем-то многократно используемым многими приложениями, тогда имеет смысл поместить ее в специализированную STS.
Есть и третье соображение - потенциальное ненужное раскрытие информации. Приложению может понадобиться только знать, имеет ли пользователь X доступ к учетной записи 123. Предоставляя список всех учетных записей, к которым имеет доступ пользователь X, вы раскрываете больше информации, чем нужно.
В качестве общего руководства утверждения лучше использовать для "крупнозернистых" атрибутов. "Мелкозернистый" контроль доступа, вероятно, лучше обрабатывать внутри приложения, где вы можете использовать оптимизацию инфраструктуры.
Вот экстремальный пример: представьте себе файловую систему. Стали бы вы кодировать в виде утверждений имена файлов, к которым пользователь имеет доступ? Вряд ли, потому что в итоге у вас могут оказаться миллионы...
Еще один экстремальный пример: если бы вы хотели реализовать безопасность на уровне строк в базе данных. Стали бы вы кодировать в виде утверждений идентификаторы рядов для каждого пользователя? Снова маловероятно, потому что их может быть много, это очень специфично для конкретного приложения, а также потому, что, вероятно, проще (и гораздо эффективнее) решить фильтрацию строк с помощью запроса к базе данных (это пример оптимизации инфраструктуры)
.