Аутентификация приложений и пользователей с использованием ядра ASP.NET

Может ли кто-нибудь указать мне какую-нибудь хорошую документацию или предоставить хорошую информацию о наилучшем способе реализации проверки подлинности и авторизации для API-интерфейса REST ASP.NET. Мне нужно сначала аутентифицировать и авторизировать приложение, а затем аутентифицировать и авторизировать пользователя.

В идеале я хочу ограничить метод контроллера, к которому может обратиться аутентифицированное приложение и/или пользователь.

Я думаю использовать AspNet.Security.OpenIdConnect.Serverenter для аутентификации приложения, но я не уверен, что лучше всего выполнить пользователя аутентификация. Возможно, повторите использование аутентификации OpenIdConnect на другой конечной точке для пользователей с другим заголовком, чтобы содержать токен пользователя.

После проверки подлинности я думаю о том, что просто использует базовую безопасность ролей, чтобы ограничить доступ к методам контроллеров.

Это правильный путь решения этой проблемы?

Ответы

Ответ 1

На самом деле это более сложный вопрос, который может показаться, потому что тип клиентов (программных клиентов), которые используют api, похоже, ведет к тому, какой тип auth * необходим. Например, в веб-приложении, где веб-приложение требуется auth *, тогда Asp.Net Identity будет работать либо с токеном, либо с файлом cookie. Однако, если другие клиенты будут потреблять предоставленные услуги (мобильные приложения, приложения WUP, тогда это может быть проще реализовать с использованием токен-аутентификации. Когда у меня возникла эта проблема, я столкнулся с проблемой, что у меня был пробел в знаниях, потому что я сделал Я действительно понял Оата, мне пришлось вернуться к основам.

https://alexbilbie.com/guide-to-oauth-2-grants/

https://www.pluralsight.com/courses/oauth2-json-web-tokens-openid-connect-introduction

Большинство обучающих программ, посвященных Identity Asp.Net "Seem", ориентированы на веб-клиентов. Хотя можно найти те, которые этого не делают. С введением ядра asp.net синтаксис изменился, и многие из старых руководств, которые показывают объединение проверки файлов cookie и токенов, больше не применимы. Кроме того, Web Api больше не отделен от других типов проектов в Visual Studio, делая изменение еще более выраженным. Вот несколько старых руководств.

http://satvasolutions.com/combine-asp-net-identity-web-api-and-mvc-best-in-a-single-web-app/

http://blog.iteedee.com/2014/03/asp-net-identity-2-0-cookie-token-authentication/

Объединить использование аутентификации как для страниц MVC, так и для страниц веб-API?

IdentityServer - это полностью действующее решение, работающее как с учетными данными клиента, так и с полномочиями учетных записей владельца ресурсов (пользователь, пароль), и Брок Аллен обычно очень чувствителен к SO под тегом

fooobar.com/questions/tagged/...

или на сайте github под вопросами, помеченными как вопросы

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

С сервером идентификации снова я должен был вернуться к основам и работать через учебные пособия, чтобы понять, как это будет работать в моем проекте.

https://identityserver4.readthedocs.io/en/release/intro/big_picture.html

Поскольку Брок быстро указал мне на другое сообщение, идентификатор asp.net ef является хранилищем пользователей и может использоваться с рабочим процессом учетных данных владельца ресурса.

Ответ 2

Для аутентификации вы можете использовать Идентификатор ядра ASP.NET, который будет использовать Microsoft.AspNetCore.Identity.EntityFrameworkCore, который сохранит идентификационные данные и схему на SQL Server, используя Entity Framework Core.

Для авторизации вы можете использовать Ролевая авторизация, которая использует Microsoft.AspNetCore.Authorization.

Вы также можете проверить это видео для обзора основной авторизации ASP.NET

Ответ 3

Я не мог найти хорошую документацию по этому вопросу, однако мне пришлось добиться того же, поэтому я сам закодировал остальные, изменив действия в стандартном шаблоне проверки подлинности ASP.NET на эквиваленты REST API.

Например, вот как я работал над действием входа:

    // POST: /Account/Login
    [HttpPost("[action]")]
    [AllowAnonymous]
    public async Task<ReturnValue<ApplicationUser>> Login([FromBody] loginModel login)
    {
        if (ModelState.IsValid)
        {
            ApplicationUser user = await _userManager.FindByEmailAsync(login.email);

            if (user == null)
            {
                return new ReturnValue<ApplicationUser>(false, "Login failed, check username and password.", null);
            }
            // else if (user.EmailConfirmed == false)
            // {
            //     return new ReturnValue<ApplicationUser>(true, "Confirm email address.", null, user);
            // }
            else
            {
                // This doesn't count login failures towards account lockout
                // To enable password failures to trigger account lockout, set lockoutOnFailure: true
                var result = await _signInManager.PasswordSignInAsync(user, login.password, (bool)login.rememberMe, lockoutOnFailure: false);
                if (result.Succeeded)
                {
                    return new ReturnValue<ApplicationUser>(true, user);
                }
                //if (result.RequiresTwoFactor)
                //{
                //    return RedirectToAction(nameof(SendCode), new { ReturnUrl = returnUrl, RememberMe = model.RememberMe });
                //}
                if (result.IsLockedOut)
                {
                    return new ReturnValue<ApplicationUser>(false, "The account is locked out.", null);
                }
            }
        }
        else
        {
            string message = string.Join("; ", ModelState.Values.SelectMany(x => x.Errors).Select(x => x.ErrorMessage));
            return new ReturnValue<ApplicationUser>(false, "Invalid login attempt: " + message, null);
        }

        // If we got this far, something failed in the model.
        return new ReturnValue<ApplicationUser>(false, "Login failed.", null);
    }

Если вы вызываете API из javascript в браузере, файлы cookie будут загружены, и вы должны будете иметь возможность разрешать дополнительные авторизации в API, если вы звоните из другого типа клиента, вы захотите обеспечить CookieContainer сохраняется для авторизированных вызовов.

С этого момента вы можете разрешить свои контроллеры REST API с помощью [Authorize] decorator через стандартные библиотеки Microsoft: https://docs.microsoft.com/en-us/aspnet/core/security/authentication/identity

Удачи.