Декларативная безопасность
Можно отказаться, запросить или заявить полномочия, вызывая классы в .NET Framework, но можно также использовать атрибуты и определять требования полномочий декларативно.
Основное достоинство использования декларативной безопасности состоит в том, что настройки доступны с помощью отражения. Возможность получить доступ к информации посредством отражения дает огромный выигрыш для системных администраторов, которые часто хотят видеть требования безопасности приложений.
Допустим, мы объявляем, что метод для выполнения должен иметь полномочие на чтение с C:.
using System;
using System.Security.Permissions;
namespace SecurityApp8 {
class Class1 {
static void Main(string[] args) {
MyClass.Method();
}
}
[FileIOPermission(SecurityAction.Assert, Read='C:\')]
class MyClass {
public static void Method() {
// реализация находится здесь
}
}
}
Помните, что если атрибуты применяются для заявления или запроса полномочий, невозможно перехватить исключения, возникающие в случае отказа действия, так как не существует обязательного кода, который можно поместить в предложение try-catch-finally.
Чтобы узнать обо всех доступных атрибутах, можно ознакомиться с перечислением System.Security.Permissions.SecurityAction.
Система безопасности на основе ролей
Как мы видели, система безопасности доступа к коду дает CLR возможность неявно решить, должен ли код выполняться и с какими полномочиями на основе свидетельства о коде. В дополнение к этому .NET предоставляет систему безопасности на базе ролей, которая определяет, может ли код выполнить действия на основе свидетельства о пользователе и его роли.
Система безопасности на основе ролей особенно полезна в ситуациях, где доступ к ресурсам является основным вопросом. Хорошим примером может служить отрасль финансов, где роли сотрудников определяют, к какой информации они имеют доступ и какие действия могут выполнить.
Система безопасности на основе ролей также является идеальной для использования в соединении с учетными записями Windows 2000, Microsoft Passport или специальным каталогом пользователя для управления доступом к ресурсам на основе Web. Например, web-сайт может ограничить доступ к своему содержимому, пока пользователь не зарегистрирует свои данные на этом сайте, и затем дополнительно предоставит доступ к специальному содержимому, только если пользователь является оплаченным подписчиком. Во многих отношениях ASP.NET делает систему безопасности на основе ролей проще, так как большая часть кода находится на сервере.
Например, если желательно реализовать службу Web, требующей аутентификации, то можно использовать подсистему учетных записей Windows 2000 и написать метод для Web таким образом, чтобы он проверял, является ли пользователь членом определенной группы пользователей Windows 2000, прежде чем предоставлять доступ к функциональности метода.
Принципал
.NET предоставляет текущему потоку выполнения простой доступ к пользователю приложения, который обозначается как Principal. Принципал является ядром системы безопасности, предоставленной .NET, на основе ролей, и через него можно получить доступ к объекту Identity пользователя, который отображается в учетной записи пользователя одного из приведенных ниже типов:
□ Учетная запись Windows
□ Учетная запись Passport
□ Пользователь, аутентифицированный с помощью cookie из ASP.NET
В качестве дополнительного бонуса система безопасности на основе ролей в .NET может создавать свои собственные принципалы, реализуя интерфейс IPrincipal. Если вы не полагаетесь на аутентификацию Windows, Passport или простую аутентификацию с помощью cookie, необходимо рассмотреть вопрос о создании своей собственной аутентификации с помощью специального класса principal.
С помощью доступа к принципалу можно делать выводы о безопасности на основе идентичности и ролей принципала. Роль является совокупностью пользователей, которые имеют одинаковые полномочия безопасности, и является единицей администрации пользователей. Например, при использовании аутентификации Windows будет применяться тип WindowsIdentity в качестве варианта Identity. Можно выбрать этот тип для выяснения, является ли пользователь членом определенной группы учетных записей пользователей Windows, а затем использовать эту информацию для решения, предоставить или отменить доступ к коду и ресурсам.
Обычно значительно легче управлять безопасностью, если доступ к ресурсам и функциональности разрешается на основе полномочий, а не ролей. Представьте сценарий, где имеется три метода, каждый из них предоставляет доступ к свойству, для которого требуется строгий контроль, чтобы гарантировать, что только авторизованному персоналу доступ к нему открыт. Если приложение имеет, скажем, четырех пользователей, то достаточно легко определить в каждом методе, какие пользователи могут и какие не могут получить доступ к методу. Однако представим ситуацию, где число свойств возрастает до девяти. Чтобы разрешить доступ для дополнительного пользователя, потенциально потребуется изменить каждый из девяти методов, хотя это является административной задачей. Даже хуже, так как пользователи меняются ролями в компании и понадобится изменять код каждый раз, когда это происходит. Если вместо этого реализовать систему, использующую роли, то можно просто добавлять и удалять пользователей из ролей, а не добавлять и удалять отдельных пользователей из приложения. Таким образом, выполнение приложения облегчается, и для каждого метода мы только ставим условие, чтобы пользователь был членом определенной группы. Ото также упрощает управление ролями, так как эту работу может делать администратор, а не разработчик приложения. Говоря проще, разработчик сосредоточивается на том, что, например, Managers, но не Secretaries, могут получить доступ к методу, а не на том, каковы возможности Julie и Bob, но не Conrad.
Система безопасности на основе ролей в .NET строится на системе безопасности из MTS и COM+ 1.0
