Книга: C# для профессионалов. Том II

Принципал

Принципал

.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 и предоставляет гибкую среду, создающую ограждения вокруг разделов приложения, которые должны быть защищены. Если система COM+ 1.0 установлена на машине, ее безопасность на основе ролей будет интерпретироваться в NET, однако COM не требуется .NET на основе ролей для функционирования системы безопасности.

Оглавление книги