Windows user asp net

Windows Authentication in ASP.NET Core

Last Modified: 2017-03-28

Using Windows Authentication in ASP.NET Core Web Applications

ASP.NET Core Windows Authentication

Время на прочтение7 мин

Количество просмотров8.1K

Для начала расскажу, что приложение, которое я разрабатывал, долго существовало на небольшом «подстольном» сервере в виде прототипа, которым в работе пользовалось небольшое число сотрудников. По прошествии некоторого времени, руководство приняло решение тиражировать это приложение в пром – с переносом на пром-сервер и организацией доступов к нему сотрудникам всего структурного подразделения.

Картинка с сайта: habr.com

Естественно, как это всегда бывает, сопровождение выдало нам список требований, которым должны соответствовать приложения, размещаемые на пром-серверах. Одним из таких требований было реализация авторизации по учетной записи Windows, а старую авторизацию по логину/паролю использовать было нельзя. О том, с какими подводными камнями мы столкнулись в ходе реализации такой, казалось бы, простой фичи, и как мы их решили, и пойдет речь в этом посте. Как я и упомянул ранее, в начальной точке этой истории у нас было классическое MVC-приложение. Информация о пользователях, их ролях (Admin, Common) и доступах к определенным действиям и процедурам хранилась в БД MS SQL. Упрощенно структуру этого сегмента БД можно представить вот так:

Картинка с сайта: habr.com

По названию таблиц можно догадаться, что в самом приложении эта связка таблиц захватывалась Entity Framework 6, а после использовалась подсистемой ASP.NET Identity. В начале сессии пользователю выводилась форма для входа, в которую он вводил свои учетные данные, после чего происходил редирект на домашнюю страницу приложения. Далее, исходя из того, какие доступы у данного пользователя прописаны в БД, и какими привилегиями он обладает, система подстраивала UI под эти данные.

Авторизация была реализована с помощью HTML-форм путём применения стандартного хелпера Html.BeginForm, отсылающего введенные данные по нажатию кнопки Submit. Вот как это выглядело с точки зрения кода:

@using (Html.BeginForm("Login", "Auth", FormMethod.Post, new { @class = "form-signin" }))
{
    @Html.AntiForgeryToken()
    <div class="form-group form-ie">
        <span class="oi oi-person"></span>
        @Html.TextBoxFor(x => x.Login, new { @class = "form-control", @placeholder = "Логин", @id = "username" })
        @Html.ValidationMessageFor(x => x.Login)
    </div>

    <div class="form-group form-ie">
        <span class="oi oi-lock-locked"></span>
        @Html.PasswordFor(x => x.Password, new { @class = "form-control", @placeholder = "Пароль", @id = "inputPassword" })
        @Html.ValidationMessageFor(x => x.Password)
    </div>
    <input type="submit" class="btn btn-mybtn-lg btn-my btn-block text-uppercase" value="Войти" />
}

Далее логин с паролем передавались в контроллер авторизации AuthController, который в себе хранил UserManager, SignInManager и AppDbContext (пронаследованный от IdentityDBContext) из ASP.NET Identity. Вот как выглядел код этого контроллера.

[AllowAnonymous]
[RoutePrefix("Auth")]
public class AuthController : Controller
{
	private AppDbContext _dbContext;
	private ApplicationSignInManager _signInManager;
	private ApplicationUserManager _userManager;
	public ApplicationSignInManager SignInManager
	{
		get
		{
			return _signInManager ?? HttpContext.GetOwinContext().Get<ApplicationSignInManager>();
		}
		private set
		{
			_signInManager = value;
		}
	}

	public ApplicationUserManager UserManager
	{
		get
		{
			return _userManager ?? HttpContext.GetOwinContext().GetUserManager<ApplicationUserManager>();
		}
		private set
		{
			_userManager = value;
		}
	}

	public AppDbContext DbContext
	{
		get
		{
			return _dbContext ?? HttpContext.GetOwinContext().Get<AppDbContext>();
		}
		private set
		{
			_dbContext = value;
		}
	}

	public AuthController()
	{
	}

	[HttpGet]
	public ActionResult Index()
	{
		return View(new AuthViewModel());
	}

	[HttpPost]
	[ValidateAntiForgeryToken]
	public async Task<ActionResult> Login(AuthViewModel model)
	{
		var result = await SignInManager.PasswordSignInAsync(model.Login, model.Password, false, false);
		if (result == SignInStatus.Success)
		{
			return RedirectToAction("Index", "Home");
		}
		Log.Warning("Ошибка авторизации: Неправильный логин или пароль");
		ModelState.AddModelError("Password", "Неправильный логин или пароль");
		return View("Index", model);
	}

	private IAuthenticationManager AuthenticationManager
	{
		get
		{
			return HttpContext.GetOwinContext().Authentication;
		}
	}

	[HttpGet]
	[ValidateAntiForgeryToken]
	public ActionResult LogOff()
	{
		AuthenticationManager.SignOut(DefaultAuthenticationTypes.ApplicationCookie);
		return RedirectToAction("Index", "Auth");
	}
}

Сам факт авторизации в системе в других контроллерах проверялся посредством применения фильтра-нотации [Authorize], а принадлежность к роли – посредством применения [Authorize(Roles = “role1”)].

[Authorize]
public class HomeController : Controller
{
	private AppDbContext _dbContext;

	public AppDbContext DbContext
	{
		get
		{
			return _dbContext ?? HttpContext.GetOwinContext().Get<AppDbContext>();
		}
		private set
		{
			_dbContext = value;
		}
	}

	public HomeController()
	{
	}

	[Authorize(Roles = "Common, Admin")]
	public ActionResult Index()
	{
		///something is happening
		return View();
	}
}

Как заметит знакомый с вышеописанным стеком человек, не происходит вообще ничего необычного – это базовые элементы, знакомые каждому ASP.NET-разработчику.

Итак, после получения требования об изменении порядка авторизации, мы стали менять его. Для тех, кто с этим не знаком — в ASP.NET существуют следующие типы авторизации, которые можно поставить как с конфига, так и с помощью шаблона Visual Studio при создании проекта:

1. Без авторизации;

2. Авторизация на основе отдельных учётных записей (логин+пароль, классика)

3. Авторизация с помощью Active Directory, Microsoft Azure или Office 365.

4. Авторизация с помощью учётной записи Windows.

Так как у нас нет возможности использовать Active Directory ввиду требований сопровождения, остаётся один вариант – авторизация с помощью УЗ Windows.

Поигравшись немного со сменой способа авторизации в пустых приложениях и убедившись, что в них всё работает, я сделал то же самое с нашим приложением, заменив authentication mode на «Windows» в web.config.

Итак, настало время прогона. Изначально я предполагал, что после изменения авторизации можно будет подгонять логин пользователя в SignInManager, после чего проводить авторизацию по-старому (только без пароля) – т.е., что SignInManager будет маппить логин с таблицей AspNetUsers и вносить в контекст текущей пользовательской сессии соответствующий AspNetIdentity. Для чистоты эксперимента я удалил себя из таблицы с пользователями. Иии…я все равно спокойно авторизовался. Покопавшись в переменных, я понял, что при смене authentication mode на «Windows» используется другой вид Identity: не AspNetIdentity, а WindowsIdentity. При использовании WindowsIdentity любой пользователь, который вошёл в Windows – априори авторизован, причем автономно – никакой связи с БД и EF не наблюдалось. Это означало, что если ничего не исправить, то…

Картинка с сайта: habr.com

Ну вы поняли ?

Так как Active Directory мы использовать не могли, текущий вариант не работал, а опыта в написании и модификации систем авторизации у меня не было – плюс, на эту фичу было отведено мало времени – я закопался в документацию по ASP.NET Identity и Windows Identity. Как оказалось – это было правильное решение.

Итак, как можно подружить ASP.NET Identity + EF и Windows Identity:

1. Сделать еще один класс – назовем его CustomAuthenticationFilter — и пронаследовать его от ActionFilterAttribute и IAuthenticationFilter.

В AuthorizeAttribute содержится метод OnAuthentication который можно переопределить в дочернем классе. В нём мы захватываем логин пользователя из Windows Identity, прикрепленного к контексту AuthenticationContext – затем с помощью контекста Entity Framework получаем доступ к таблице с пользователями и проверяем, есть ли пользователь в списке. Если его нет – в методе вернуть false.

Затем из AuthorizeAttribute в нашем классе необходимо переопределить обработчик событий OnAuthenticationChallenge, который позволяет задать реакцию системы в случае, если метод OnAuthentication, переопределенный ранее выдаст false. В нашем случае мы будем перенаправлять пользователя на страницу, где сообщим ему, что к приложению необходимо получить доступ (401).

public class CustomAuthenticationFilter : ActionFilterAttribute, IAuthenticationFilter
{
	public void OnAuthentication(AuthenticationContext filterContext)
	{
		var dbContext = filterContext.HttpContext.GetOwinContext().Get<AppDbContext>();

		var username = filterContext.HttpContext.User.Identity.Name;

		var userMatches = dbContext.Users.Where(x => x.UserName == username);

		if (string.IsNullOrEmpty(username) || userMatches.Count() != 1)
		{ 
			filterContext.Result = new HttpUnauthorizedResult();
		}
	}

	public void OnAuthenticationChallenge(AuthenticationChallengeContext filterContext)
	{
		if (filterContext.Result == null || filterContext.Result is HttpUnauthorizedResult)
		{
			filterContext.Result = new RedirectToRouteResult(
				 new RouteValueDictionary{
					 { "controller", "Error" },
					 { "action", "NotAuthorized" }
			});
		}
	}
}

1. Для того, чтобы сделать вариант, предполагающий дополнительную проверку роли, помимо проверки факта наличия пользователя, необходимо в том же или новом классе пронаследоваться от AuthorizeAttribute. Для упрощения чтения я сделал новый класс.

Идеология здесь следующая:

Делаем конструктор, в который извне передаем список разрешенных ролей, например, { “Admin”, “Common”}.

Переопределяем метод AuthorizeCore, в котором реализуем поиск пользователя по образцу предыдущего класса, а потом через тот же контекст EF достаем список ролей пользователя и матчим его с тем списком, который прилетает через конструктор. Если матч есть – пользователь «достоин».

Картинка с сайта: habr.com

• Далее переопределяем обработчик HandleUnauthorizedRequest, где мы выдаем пользователю стилизованную ошибку 403.

public class CustomAuthorizeAttribute : AuthorizeAttribute
{
	private readonly string[] allowedRoles;
	public CustomAuthorizeAttribute(params string[] roles)
	{
		allowedRoles = roles;
	}
	protected override bool AuthorizeCore(HttpContextBase httpContext)
	{
		var dbContext = httpContext.GetOwinContext().Get<AppDbContext>();

		var username = httpContext.User.Identity.Name;
		var userMatches = dbContext.Users.Where(x => x.Name == username);

		if (!string.IsNullOrEmpty(username) && userMatches.Count() == 1)
		{
			var userId = userMatches.First().Id;
			var userRole = (from u in dbContext.Users
							join r in dbContext.Roles on u.Roles.FirstOrDefault().RoleId equals r.Id
							where u.Id == userId
							select new
							{
								r.Name
							}).FirstOrDefault();

			foreach(var role in allowedRoles)
			{
				if (role == userRole.Name) return true;
			}
		}

		return false;
	}

	protected override void HandleUnauthorizedRequest(AuthorizationContext filterContext)
	{
		filterContext.Result = new RedirectToRouteResult(
			new RouteValueDictionary
			{
				{ "controller", "Home" },
				{ "action", "AccessDenied" }
			});
	}
}

А теперь магия – я думаю, вы уже догадались, что с помощью этих двух классов мы разработали фильтры, аналогичные [Authorize] и [Authorize(Roles = “role1”)].

Таким образом, изначально столкнувшись с невозможностью ASP.NET Identity и Windows Identity работать из коробки вместе, я переопределил сами фильтры, отредактировав их логику до той, что мне требуется. Надеюсь, вам поможет информация из этого поста, если вы столкнетесь с аналогичной ситуацией. Удачи!

This article shows how authorization could be implemented for an ASP.NET Core MVC application. The authorization logic is extracted into a separate project, which is required by some certification software requirements. This could also be deployed as a separate service.

Code: https://github.com/damienbod/AspNetCoreWindowsAuth

Blogs in this series:

• Supporting both Local and Windows Authentication in ASP.NET Core MVC using IdentityServer4
• ASP.NET Core Authorization for Windows, Local accounts

History

2020-08-23 Updated to .NET Core 3.1, IdentityServer4 V4

2019-09-12 Updated to .NET Core 3.0

Application Authorization Service

The authorization service uses the claims returned for the identity of the MVC application. The claims are returned from the ASP.NET Core MVC client app which authenticates using the OpenID Connect Hybrid flow. The values are then used to create or define the authorization logic.

The authorization service supports a single API method, IsAdmin. This method checks if the username is a defined admin, and that the person/client used a Windows account to login.

using System;

namespace AppAuthorizationService
{
    public class AppAuthorizationService : IAppAuthorizationService
    {
        public bool IsAdmin(string username, string providerClaimValue)
        {
            return RulesAdmin.IsAdmin(username, providerClaimValue);
        }
    }
}

The rules define the authorization process. This is just a simple static configuration class, but any database, configuration files, authorization API could be used to check, define the rules.

In this example, the administrators are defined in the class, and the Windows value is checked for the claim parameter.

using System;
using System.Collections.Generic;
using System.Text;

namespace AppAuthorizationService
{
    public static class RulesAdmin
    {

        private static List<string> adminUsers = new List<string>();

        private static List<string> adminProviders = new List<string>();

        public static bool IsAdmin(string username, string providerClaimValue)
        {
            if(adminUsers.Count == 0)
            {
                AddAllowedUsers();
                AddAllowedProviders();
            }

            if (adminUsers.Contains(username) && adminProviders.Contains(providerClaimValue))
            {
                return true;
            }

            return false;
        }

        private static void AddAllowedUsers()
        {
            adminUsers.Add("SWISSANGULAR\\Damien");
        }

        private static void AddAllowedProviders()
        {
            adminProviders.Add("Windows");
        }
    }
}

ASP.NET Core Policies

The application authorization service also defines the ASP.NET Core policies which can be used by the client application. An IAuthorizationRequirement is implemented.

using Microsoft.AspNetCore.Authorization;
 
namespace AppAuthorizationService
{
    public class IsAdminRequirement : IAuthorizationRequirement{}
}

The IAuthorizationRequirement implementation is then used in the AuthorizationHandler implementation IsAdminHandler. This handler checks, validates the claims, using the IAppAuthorizationService service.

using Microsoft.AspNetCore.Authorization;
using System;
using System.Linq;
using System.Threading.Tasks;

namespace AppAuthorizationService
{
    public class IsAdminHandler : AuthorizationHandler<IsAdminRequirement>
    {
        private IAppAuthorizationService _appAuthorizationService;

        public IsAdminHandler(IAppAuthorizationService appAuthorizationService)
        {
            _appAuthorizationService = appAuthorizationService;
        }

        protected override Task HandleRequirementAsync(AuthorizationHandlerContext context, IsAdminRequirement requirement)
        {
            if (context == null)
                throw new ArgumentNullException(nameof(context));
            if (requirement == null)
                throw new ArgumentNullException(nameof(requirement));

            var claimIdentityprovider = context.User.Claims.FirstOrDefault(t => t.Type == "http://schemas.microsoft.com/identity/claims/identityprovider");

            if (claimIdentityprovider != null && _appAuthorizationService.IsAdmin(context.User.Identity.Name, claimIdentityprovider.Value))
            {
                context.Succeed(requirement);
            }

            return Task.CompletedTask;
        }
    }
}

As an example, a second policy is also defined, which checks that the http://schemas.microsoft.com/identity/claims/identityprovider claim has a Windows value.

using Microsoft.AspNetCore.Authorization;

namespace AppAuthorizationService
{
    public static class MyPolicies
    {
        private static AuthorizationPolicy requireWindowsProviderPolicy;

        public static AuthorizationPolicy GetRequireWindowsProviderPolicy()
        {
            if (requireWindowsProviderPolicy != null) return requireWindowsProviderPolicy;

            requireWindowsProviderPolicy = new AuthorizationPolicyBuilder()
                  .RequireClaim("http://schemas.microsoft.com/identity/claims/identityprovider", "Windows")
                  .Build();

            return requireWindowsProviderPolicy;
        }
    }
}

Using the Authorization Service and Policies

The Authorization can then be used, by adding the services to the Startup of the client application.

services.AddSingleton<IAppAuthorizationService, AppAuthorizationService.AppAuthorizationService>();
services.AddSingleton<IAuthorizationHandler, IsAdminHandler>();

services.AddAuthorization(options =>
{
	options.AddPolicy("RequireWindowsProviderPolicy", MyPolicies.GetRequireWindowsProviderPolicy());
	options.AddPolicy("IsAdminRequirementPolicy", policyIsAdminRequirement =>
	{
		policyIsAdminRequirement.Requirements.Add(new IsAdminRequirement());
	});
});

The policies can then be used in a controller and validate that the IsAdminRequirementPolicy is fulfilled.

using Microsoft.AspNetCore.Authorization;
using Microsoft.AspNetCore.Mvc;

namespace MvcHybridClient.Controllers
{
    [Authorize(Policy = "IsAdminRequirementPolicy")]
    public class AdminController : Controller
    {
        public IActionResult Index()
        {
            return View();
        }
    }
}

Or the IAppAuthorizationService can be used directly if you wish to mix authorization within a controller.

private IAppAuthorizationService _appAuthorizationService;

public HomeController(IAppAuthorizationService appAuthorizationService)
{
	_appAuthorizationService = appAuthorizationService;
}

public IActionResult Index()
{
	// Windows or local => claim http://schemas.microsoft.com/identity/claims/identityprovider
	var claimIdentityprovider = 
	  User.Claims.FirstOrDefault(t => 
	    t.Type == "http://schemas.microsoft.com/identity/claims/identityprovider");

	if (claimIdentityprovider != null && 
	  _appAuthorizationService.IsAdmin(
	     User.Identity.Name, 
		 claimIdentityprovider.Value)
	)
	{
		// yes, this is an admin
		Console.WriteLine("This is an admin, we can do some specific admin logic!");
	}

	return View();
}

If an admin user from Windows logged in, the admin view can be accessed.

Or the local guest user only sees the home view.

Notes:

This is a good way of separating the authorization logic from the business application in your software. Some certified software processes, require that the application authorization, authentication is audited before each release, for each new deployment if anything changed.
By separating the logic, you can deploy, update the business application without doing a security audit. The authorization process could also be deployed to a separate process if required.

Links:

https://docs.microsoft.com/en-us/aspnet/core/security/authorization/views?view=aspnetcore-2.1&tabs=aspnetcore2x

https://docs.microsoft.com/en-us/aspnet/core/security/authentication/?view=aspnetcore-2.1

https://mva.microsoft.com/en-US/training-courses/introduction-to-identityserver-for-aspnet-core-17945

https://stackoverflow.com/questions/34951713/aspnet5-windows-authentication-get-group-name-from-claims/34955119

https://github.com/IdentityServer/IdentityServer4.Templates

https://docs.microsoft.com/en-us/iis/configuration/system.webserver/security/authentication/windowsauthentication/

How to use Windows Authentication for ASP.NET Core Web APIs? We will try to do something like that in today’s tutorial using Min APIs.

First, create a new empty asp.net web project using the below command:
dotnet new web -o minwinauth

Then, switch to the minwinauth folder and add Negotiate package to the project since Windows Authentication requires the library:
dotnet add package Microsoft.AspNetCore.Authentication.Negotiate

Open your project using VS Code / any of your favourite IDE and paste the code below to the Program.cs:

using Microsoft.AspNetCore.Authentication.Negotiate;
using Microsoft.AspNetCore.Authorization;

var builder = WebApplication.CreateBuilder(args);

// Add services to the container.
// To have Windows Authentication, we need to add NegotiateDefaults.AuthenticationScheme
builder.Services.AddAuthentication(NegotiateDefaults.AuthenticationScheme).AddNegotiate();
builder.Services.AddAuthorization();

var app = builder.Build();

// Configure the HTTP request pipeline.
app.UseAuthentication();
app.UseAuthorization();

app.MapGet("/", () => "Hello World!");
// Authorize attribute make the API needs authentication, and Negotiate... is for Windows Authentication.
app.MapGet("/admin", [Authorize(AuthenticationSchemes = NegotiateDefaults.AuthenticationScheme)] (HttpContext context) =>
    "The /admin endpoint is for authorizers only. User ID: " + context.User.Identity?.Name);

app.Run();

Run the project using the command below:
dotnet run

If you browse the site, you will get “Hello World!” without you keying in any credential due to root directory is don’t need authentication. But if you browse /admin, a login dialog box will appear, and you need to key in the Windows credential.

If you click cancel or key in a wrong credential, you will get 401 Unauthorized with authentication method is Negotiate.

Картинка с сайта: mycsharpdeveloper.wordpress.com

But if you key in correct Windows credential, you will able to login and see the message like below:
The /admin endpoint is for authorizers only. User ID: xxx/yyy

PS:
Please note this working in Windows environment only, if you try in Linux environment, you most probably will get 401 unauthorized due to no authentication can be made. If you want Linux to support this Windows Authentication, you need to setup the Linux environment configuration as stated in ASP.NET Core documentation https://docs.microsoft.com/en-us/aspnet/core/security/authentication/windowsauth?view=aspnetcore-6.0&tabs=visual-studio