GenericIdentity
и GenericPrincipal
- самый простой способ описания пользователя как «принципала». Это можно использовать для проверки безопасности в приложении, не зависящей от реализации, т. Е. Если пользователь входит в систему как «Fred» с разрешениями «User» и «Admin»:
string[] roles = { "User", "Admin" };
Thread.CurrentPrincipal = new GenericPrincipal(
new GenericIdentity("Fred"), roles);
Вы можете сделать это в момент входа клиента в winform, или для этого есть определенные моменты в WCF, ASP.NET и т. Д.
Затем более поздний код, без необходимости знать , как обрабатываются эти разрешения, может проверить это разрешение - либо через IsInRole , либо декларативно:
[PrincipalPermission(SecurityAction.Demand, Role = "Admin")]
void SomeAdminFunction() { }
Некоторый полезный служебный код здесь - это обернутые нулем обертки вокруг принципала / идентичности:
public static string GetUsername() {
IPrincipal principal = Thread.CurrentPrincipal;
IIdentity identity = principal == null ? null : principal.Identity;
return identity == null ? null : identity.Name;
}
public static bool IsInRole(string role) {
IPrincipal principal = Thread.CurrentPrincipal;
return principal == null ? false : principal.IsInRole(role);
}
Тогда в вашем DAL может быть какой-то код аудита:
row.UpdatedBy = MyUtilityClass.GetUsername();
GenericPrincipal
полезно для простых случаев простого имени пользователя и набора известных ролей.
Более сложные основные реализации могут, например, выполнять проверку доступа «по требованию» - то есть, пока вы не попросите роль «Foo», которую он не знает, - а затем узнает (общаясь с веб-сервисом, базой данных, активным каталог и т. д.) и кэширует результат для последующего доступа. Это полезно, когда список потенциальных ролей велик, а количество ролей, обычно запрашиваемых в reality , мало.
Вы также можете использовать принципала для хранения дополнительной идентификационной информации, которая необходима только в определенных контекстах - например, токен безопасности. Вызывающие могут проверить участника с помощью as
, чтобы проверить, поддерживает ли он дополнительные данные.
Использование «принципала» полезно, потому что ваш код обработки логики может говорить об идентичности, без необходимости знать, является ли это winforms, ASP.NET, WCF, службой Windows и т. Д. - это абстрактно. Кроме того, некоторый сторонний код также будет общаться с принципалом.
В качестве другого примера - я написал здесь пример кода , который показывает, как использовать принципал для управления доступом к элементам управления winform через конструктор (через IExtenderProvider
), который помещает дополнительные записи в сетку свойств в VS).