Я работаю над своим первым базовым веб-приложением do-1022 *. По большей части мне нравятся все изменения, но я борюсь с чем-то, что было довольно основополагающим для c в Framework - с использованием токена Windows с пользовательским хранилищем ролей. Я проведу свой ход мыслей, чтобы кто-то мог сказать мне, где он сошел с рельсов:
Справочная информация: Один веб-сайт / пользовательский интерфейс, который подключается к двум различным службам RESTful, чтобы на самом деле делать свои вещи. Нам нужно все это обезопасить. Все на месте и внутренне, поэтому мы используем IIS и Windows Аутентификацию с хранилищем разрешений для приложения c, как мы всегда это делали.
У меня есть Windows Аутентификация включена в launchSettings, потому что это то, что позволяет мне получить идентификатор пользователя из токена. Это прекрасно работает, и я могу вернуть имя обратно с помощью метода обслуживания. Я мог бы взломать некоторые поиски в базе данных, но я действительно хочу использовать основанный на политике подход, особенно потому, что мы собираемся в конечном итоге перейти на AWS, в будущем, что означает рефакторинг нашей безопасности. Поскольку это система из трех частей, я подумал, что использование повара ie для увеличения токена Windows может быть хорошей идеей. Я использовал это https://github.com/blowdart/AspNetAuthorizationWorkshop в качестве руководства, просто преобразовывая методы контроллера MVC в методы контроллера API. Это кажется многообещающим, но это также то, где я начинаю разочаровываться.
Используя различные конфигурации атрибутов Authorize, я могу получить перенаправления для работы с ложного метода «GetUserName» на метод Login. Однако, когда я делаю это, я получаю ошибку HTTP Error 400. The size of the request headers is too long.
.
Мне действительно не нужен повар ie, но тогда мне нужно будет добавить претензии к принципалу в центральном местоположении ( запускать?). Примеры, которые я нашел по этому поводу ... отсутствуют.
Вот соответствующая часть моего Startup.ConfigureServices:
public void ConfigureServices(IServiceCollection services)
{
services.AddAuthentication(IISDefaults.AuthenticationScheme)
.AddCookie(CookieAuthenticationDefaults.AuthenticationScheme,
options =>
{
options.LoginPath = new PathString("/Account/login/");
options.AccessDeniedPath = new PathString("/Account/forbidden/");
});
Контроллер учетных записей выглядит (частично) так:
[Authorize]
[ApiController]
[Route("[controller]")]
public class AccountController : ControllerBase
{
[Authorize(AuthenticationSchemes = CookieAuthenticationDefaults.AuthenticationScheme)]
[HttpGet]
public string Get()
{
var username = User.Identity.Name;
return $"Hello {username}";
}
//[AllowAnonymous]
[Authorize(AuthenticationSchemes = IISDefaults.AuthenticationScheme)]
[HttpGet("login")]
public async Task<IActionResult> Login(string returnUrl = null)
{
const string Issuer = "https://contoso.com";
var claims = new List<Claim>
{
new Claim("Random", "MyRandom")
};
var userIdentity = User.Identity as ClaimsIdentity;
userIdentity.AddClaims(claims);
var userPrincipal = new ClaimsPrincipal(userIdentity);
var myPrincipal = User;
await HttpContext.SignInAsync(
CookieAuthenticationDefaults.AuthenticationScheme,
myPrincipal,
new AuthenticationProperties
{
ExpiresUtc = DateTime.UtcNow.AddMinutes(20),
IsPersistent = false,
AllowRefresh = false
});
if (string.IsNullOrWhiteSpace(returnUrl))
return Redirect(returnUrl);
return Accepted();
}
Любая помощь будет принята с благодарностью.