У меня есть приложение, которое использует Windows Auth в aspnet 5 MVC 6 (наблюдение за использованием IIS + IISPlatformHandler)
Как я могу ограничить доступ к контроллеру по группе AD?
Я попытался сделать что-то вроде следующего, но это не сработает :( Когда я смотрю на свои пользовательские утверждения, я вижу много групп и утверждений, которые выглядят как SID ex. {S-1-5-4}
[Authorize(Roles = "DOMAIN\\GROUP")
public class myController : Controller{...}
По состоянию на июль 2016 года я обнаружил, что с .NET Core RTM (WebAPI) теперь работает следующее:
[Authorize(Roles = @"DOMAIN\Group")]
Вот зависимости project.json на случай, если вы также захотите протестировать:
{
"title": "My App",
"copyright": "2016",
"description": "WebAPI",
"dependencies": {
"Microsoft.AspNetCore.Mvc": "1.0.0",
"Microsoft.AspNetCore.Server.IISIntegration": "1.0.0",
"Microsoft.AspNetCore.Server.Kestrel": "1.0.0",
"Microsoft.Extensions.Configuration.EnvironmentVariables": "1.0.0",
"Microsoft.Extensions.Configuration.FileExtensions": "1.0.0",
"Microsoft.Extensions.Configuration.Json": "1.0.0",
"Microsoft.Extensions.Logging": "1.0.0",
"Microsoft.Extensions.Logging.Console": "1.0.0",
"Microsoft.Extensions.Logging.Debug": "1.0.0",
"Microsoft.Extensions.Options.ConfigurationExtensions": "1.0.0",
"Microsoft.NETCore.App": {
"version": "1.0.0",
"type": "platform"
},
"Newtonsoft.Json": "9.0.1",
"NLog.Extensions.Logging": "1.0.0-rtm-alpha2"
},
Проблема в том, что в DNX нет system.DirectorySevices. Я начал обсуждение следующей проблемы github.
https://github.com/aspnet/Home/issues/1232#issuecomment-171264286
Нам пришлось иметь дело с текущими битами RC1, и мы попытались свести к минимуму настройку, поскольку похоже, что в RC2 все будет исправлено. В итоге мы создали класс Constants, в котором в качестве переменной использовались имена групп AD, о которых мы заботились, а затем в настоящее время значением константы является SID. Затем в нашем коде мы использовали константу вместо того, чтобы жестко задавать значение SID для роли. Таким образом, когда в будущем что-то будет исправлено, у нас будет возможность просто изменить значения (заменить sid именами групп) для констант вместо того, чтобы выполнять поиск и замену во всех контроллерах. Мы также закончили тем, что написали простой API, чтобы мы могли получить все ассоциации Name/Sid. Код для этого
[HttpGet("[action]")]
public List<Tuple<string, string>> GetSids()
{
List<Tuple<string, string>> results = new List<Tuple<string, string>>();
using (PrincipalContext pc = new PrincipalContext(ContextType.Domain))
{
using (GroupPrincipal gp = new GroupPrincipal(pc))
{
using (PrincipalSearcher searcher = new PrincipalSearcher(gp))
{
foreach (var found in searcher.FindAll())
{
if (found is GroupPrincipal)
{
results.Add(new Tuple<string, string>(found.Name, found.Sid.Value));
}
}
}
}
}
return results;
}
Я только что столкнулся с очень похожей ситуацией, когда наши роли и уровни авторизации сильно отклонялись от того, что ASP.NET изначально мог предоставить. Итак, мы создали собственный пользовательский атрибут, унаследованный от AuthorizeAttribute, и он работал очень хорошо!
У меня нет опыта работы с компонентом AD, но удачный поиск показал, что этот разработчик:
Его код выглядит прямолинейным и, за исключением части AD, кажется таким же, как тот, который у нас работает.
Обратите внимание: в настоящее время лучшим методом авторизации являются политики авторизации. Но я сомневаюсь, что даже самое умное использование этого шаблона поможет вам легко добраться до AD. Если вам интересно, вы можете увидеть предложенный метод здесь.
