Аутентификация, Авторизация, Пользователь и Ролевое управление и общая безопасность в.NET
На основе Вашего определения, нет. Даже остроумие новейшие графические библиотеки можно ожидать делать набор тестирования на различных платформах.
Flash, вероятно, был бы лучшим. Широкое распространение и лучше при том, чтобы выглядеть одинаково через различные платформы.
6 ответов
Для общей безопасности, вы можете найти встроенный основной код полезным; пользовательский объект (и их роли) контролируются в .NET «принципалом», но полезно сама среда выполнения может обеспечить это.
Реализация принципала может быть определена реализацией, и вы обычно можете внедрить свою собственную; , например, в WCF .
Чтобы увидеть, как среда выполнения обеспечивает грубый доступ (т.е. к каким функциям можно получить доступ, но не ограничиваясь конкретными данными ):
static class Roles {
public const string Administrator = "ADMIN";
}
static class Program {
static void Main() {
Thread.CurrentPrincipal = new GenericPrincipal(
new GenericIdentity("Fred"), new string[] { Roles.Administrator });
DeleteDatabase(); // fine
Thread.CurrentPrincipal = new GenericPrincipal(
new GenericIdentity("Barney"), new string[] { });
DeleteDatabase(); // boom
}
[PrincipalPermission(SecurityAction.Demand, Role = Roles.Administrator)]
public static void DeleteDatabase()
{
Console.WriteLine(
Thread.CurrentPrincipal.Identity.Name + " has deleted the database...");
}
}
Однако это не помогает с детализированным доступом (например, «Фред может получить доступ к клиенту A, но не к клиенту B»).
Дополнительно; Конечно, для детализации вы можете просто проверить требуемые роли во время выполнения, проверив IsInRole для принципала:
static void EnforceRole(string role)
{
if (string.IsNullOrEmpty(role)) { return; } // assume anon OK
IPrincipal principal = Thread.CurrentPrincipal;
if (principal == null || !principal.IsInRole(role))
{
throw new SecurityException("Access denied to role: " + role);
}
}
public static User GetUser(string id)
{
User user = Repository.GetUser(id);
EnforceRole(user.AccessRole);
return user;
}
Вы также можете написать свои собственные объекты принципала / удостоверения, которые будут выполнять ленивые тесты / кэширование ролей, вместо того, чтобы знать их все заранее:
class CustomPrincipal : IPrincipal, IIdentity
{
private string cn;
public CustomPrincipal(string cn)
{
if (string.IsNullOrEmpty(cn)) throw new ArgumentNullException("cn");
this.cn = cn;
}
// perhaps not ideal, but serves as an example
readonly Dictionary<string, bool> roleCache =
new Dictionary<string, bool>();
public override string ToString() { return cn; }
bool IIdentity.IsAuthenticated { get { return true; } }
string IIdentity.AuthenticationType { get { return "iris scan"; } }
string IIdentity.Name { get { return cn; } }
IIdentity IPrincipal.Identity { get { return this; } }
bool IPrincipal.IsInRole(string role)
{
if (string.IsNullOrEmpty(role)) return true; // assume anon OK
lock (roleCache)
{
bool value;
if (!roleCache.TryGetValue(role, out value)) {
value = RoleHasAccess(cn, role);
roleCache.Add(role, value);
}
return value;
}
}
private static bool RoleHasAccess(string cn, string role)
{
//TODO: talk to your own security store
}
}
Изучите поставщиков членства ASP.NET . Я не думаю, что стандартный SQLMembershipProvider будет работать в вашем случае, но достаточно легко развернуть собственного провайдера.
WCF имеет богатую функциональность, связанную с безопасностью, которая обеспечивает как авторизацию, так и аутентификацию. Подробно здесь: http://msdn.microsoft.com/en-us/library/ms735093.aspx
Я бы взглянул на что-то вроде CSLA.net: Expert C # 2008 Business Objects
Он должен предоставить все, что вам нужно.
Я думаю, вы здесь рассматриваете несколько отдельных проблем - не случайно большинство систем безопасности разделяют аутентификацию и авторизацию.
Для аутентификации более серьезный вопрос - логистический. Или есть логическое место для жизни этих пользователей, будь то локально в приложении, в Active Directory, каком-либо другом хранилище LDAP или даже в каком-то другом приложении. Где именно - неважно - нам просто нужно уметь точно идентифицировать пользователей и, желательно, сделать эту задачу чьей-то проблемой. В конце концов, вам действительно нужен уникальный идентификатор и уверенность в том, что Боб из Бухгалтерии на самом деле Боб из Бухгалтерии.
Авторизация - более интересная часть проблемы. Я думаю, что если это действительно детально, вы действительно хотите управлять этим полностью в своем приложении, независимо от того, откуда пришли пользователи. Марк Гравелл действительно нашел хороший способ смоделировать, по крайней мере, некоторые из них - использование некоторой пользовательской реализации IPrincipal и PrincipalPermission для управления вещами - очень простой способ начать работу. Помимо этого, вы можете использовать такие методы, как этот , чтобы принимать более сложные решения об авторизации в довольно чистой манере.
мой ответ, вероятно, зависит от ответа на этот вопрос: Является ли это корпоративным приложением, которое живет в сети с Active Directory?
ЕСЛИ ответ «да», то эти Вот шаги, которые я бы предложил:
1) Создайте глобальные группы для вашего приложения, в моем случае у меня была группа APPUSER и группа APPADMIN.
2) Обеспечьте доступ к вашему SQL-серверу в режиме СМЕШАННОЙ АУТЕНТИФИКАЦИИ режим, а затем назначьте свою группу (группы) APPUSER в качестве входа в систему SQL SERVER в вашу базу данных с соответствующими правами CRUD для вашей базы данных и убедитесь, что вы получаете доступ к SQL SERVER с Trusted Connection = True в строке подключения.
На этом этапе ваше хранилище AD будет отвечать за аутентификацию. Поскольку вы получаете доступ к приложению через НАДЕЖНОЕ СОЕДИНЕНИЕ, он передаст удостоверение учетной записи, на которой запущено приложение, на SQL Server.
Теперь для АВТОРИЗАЦИИ (т. Е. Сообщая вашему приложению, что разрешено делать зарегистрированному пользователю) достаточно просто запросить в AD список групп, членом которых является зарегистрированный пользователь. Затем проверьте соответствующие имена групп и создайте свой пользовательский интерфейс на основе членства следующим образом.
Мои приложения работают следующим образом:
- При запуске приложения учетные данные основаны на вошедшем в систему пользователю, это основной аспект аутентификации (т.е. они могут войти в систему, следовательно, они существуют)
- Я получаю все группы для рассматриваемого удостоверения Windows
- Я проверяю стандартную группу ПОЛЬЗОВАТЕЛЯ - если эта группа не существует для рассматриваемого удостоверения Windows, тогда это ' s Аутентификация FAIL
- Я проверяю группу пользователей ADMIN. Имея это в группах пользователей, я изменяю пользовательский интерфейс, чтобы разрешить доступ к компонентам администрирования.
- Отображение пользовательского интерфейса
Затем у меня есть объект PRINCIPLE с определенные права / и т.д. на нем, или я использую ГЛОБАЛЬНЫЕ переменные, к которым я могу получить доступ, чтобы определить соответствующий пользовательский интерфейс при создании моих форм (то есть, если мой пользователь не является членом группы ADMIN, я бы скрывал все кнопки DELETE) .
Почему я предлагаю это?
Это вопрос развертывания.
По моему опыту, большинство корпоративных приложений развертываются сетевыми инженерами, а не программистами, поэтому наличие аутентификации / авторизации в сфере ответственности AD имеет смысл, поскольку это то, к чему обращаются сетевые специалисты, когда вы обсуждаете аутентификацию / Авторизация.
Кроме того, во время создания новых пользователей для сети сетевой инженер (или тот, кто отвечает за создание новых сетевых пользователей) более склонен помнить о выполнении групповых назначений, пока они находятся в AD, чем о том, что им нужно войти в дюжину приложений для анализа назначений авторизации.
Это помогает с лабиринтом разрешений и прав, которые необходимо предоставить новым сотрудникам или отказать тем, кто покидает компанию, и поддерживает аутентификацию и авторизацию в центральном репозитории, которому он принадлежит (например, в AD @ Контроллер домена уровень).
Сетевой инженер (или тот, кто отвечает за создание новых сетевых пользователей) более склонен помнить о выполнении групповых назначений, пока они находятся в AD, чем о том, что им приходится заходить в дюжину приложений для анализа назначений авторизации.Это помогает с лабиринтом разрешений и прав, которые необходимо предоставить новым сотрудникам или отказать тем, кто покидает компанию, и поддерживает аутентификацию и авторизацию в центральном репозитории, которому он принадлежит (то есть в AD @ Контроллер домена уровень).
Сетевой инженер (или тот, кто отвечает за создание новых сетевых пользователей) более склонен помнить о выполнении групповых назначений, пока они находятся в AD, чем о том, что им приходится заходить в дюжину приложений для анализа назначений авторизации.Это помогает с лабиринтом разрешений и прав, которые необходимо предоставить новым сотрудникам или отказать тем, кто покидает компанию, и поддерживает аутентификацию и авторизацию в центральном репозитории, которому он принадлежит (то есть в AD @ Контроллер домена уровень).