Аутентификация по локальной AD в приложении Angular - PullRequest
0 голосов
/ 12 июня 2019

Я разрабатывал приложение Angular с бэкэндом (сервисами) .NET Core. Задача состоит в том, чтобы включить интегрированную аутентификацию, т. Е. Сделать так, чтобы она работала с локальным пользователем без проблем, поэтому я подключаюсь к моей машине (подключенной к локальной AD) один раз, и веб-приложение позволяет мне войти без необходимости повторной регистрации. Мы работали с Identity Server 4 и намеревались реализовать этот сценарий, используя его.

На официальном веб-сайте есть небольшая документация, касающаяся аутентификации Windows (например, в Active Directory): http://docs.identityserver.io/en/latest/topics/windows.html, но она мало что объясняет. Согласно моей информации, для того, чтобы этот сценарий работал, браузер использует либо Kerberos, либо NTLM. Ни один из них не упоминается в документах IS4. Мне не хватает понимания того, как собираются локальные учетные данные и как IS4 «знает», что пользователь принадлежит AD? Как я могу убедиться, что только пользователи из определенного домена имеют доступ к моему приложению?

Я нашел здесь кое-что работающее https://github.com/damienbod/AspNetCoreWindowsAuth, но вопросы остались прежними. Несмотря на то, что я смог получить доступ к приложению с моей локальной учетной записью, я не понимаю поток.

Я ожидаю, что пользователь, использующий приложение в локальной сети, войдет в приложение без ввода логина / пароля (после того, как он уже вошел в Windows). Это что-то достижимое?

Ответы [ 3 ]

1 голос
/ 12 июня 2019

Identity Server предназначен для использования в качестве Identity Provider. Если вам нужно поговорить с AD, вы должны увидеть архитектуру шлюза федерации, которую они предлагают, используя IAuthenticationSchemeProvider. Где Identity Server выступает в качестве конечной точки и взаимодействует с вашей AD.

Это ссылка:

http://docs.identityserver.io/en/latest/topics/federation_gateway.html

У вас есть контроль для программного доступа к вашей AD и передачи правильных учетных данных для проверки подлинности. Этот шаг должен быть сделан на вашем Identity Server. После того, как вы пройдете аутентификацию, вы должны будете снова перенаправиться в ваше приложение. Что касается вашего последнего вопроса, ответ - да, если ваш веб-сайт размещен в интрасети, и у вас есть доступ к AD, вам не нужно захватывать свои учетные данные в качестве пользовательского ввода, вы можете программно связаться с AD, как я сказал ,

Ниже приведен код, который я использую для подключения к моей активной директории

В классе ExternalController, который вы получаете, когда используете IdentityServer, у вас есть это: (я не помню, насколько я изменился по сравнению с исходным кодом, но вы должны понять)

    /// <summary>
    /// initiate roundtrip to external authentication provider
    /// </summary>
    [HttpGet]
    public async Task<IActionResult> Challenge(string provider, string returnUrl)
    {
        if (string.IsNullOrEmpty(returnUrl)) returnUrl = "~/";

        // validate returnUrl - either it is a valid OIDC URL or back to a local page
        if (Url.IsLocalUrl(returnUrl) == false && _interaction.IsValidReturnUrl(returnUrl) == false)
        {
            // user might have clicked on a malicious link - should be logged
            throw new Exception("invalid return URL");
        }

        if (AccountOptions.WindowsAuthenticationSchemeName == provider)
        {
            // windows authentication needs special handling
            return await ProcessWindowsLoginAsync(returnUrl);
        }
        else
        {
            // start challenge and roundtrip the return URL and scheme 
            var props = new AuthenticationProperties
            {
                RedirectUri = Url.Action(nameof(Callback)),
                Items =
                {
                    { "returnUrl", returnUrl },
                    { "scheme", provider },
                }
            };

            return Challenge(props, provider);
        }
    }

private async Task<IActionResult> ProcessWindowsLoginAsync(string returnUrl)
        {
            // see if windows auth has already been requested and succeeded
            var result = await HttpContext.AuthenticateAsync(AccountOptions.WindowsAuthenticationSchemeName);
            if (result?.Principal is WindowsPrincipal wp)
            {
                // we will issue the external cookie and then redirect the
                // user back to the external callback, in essence, testing windows
                // auth the same as any other external authentication mechanism
                var props = new AuthenticationProperties()
                {
                    RedirectUri = Url.Action("Callback"),
                    Items =
                    {
                        { "returnUrl", returnUrl },
                        { "scheme", AccountOptions.WindowsAuthenticationSchemeName },
                    }
                };

                var id = new ClaimsIdentity(AccountOptions.WindowsAuthenticationSchemeName);
                id.AddClaim(new Claim(JwtClaimTypes.Subject, wp.Identity.Name));
                id.AddClaim(new Claim(JwtClaimTypes.Name, wp.Identity.Name));

                // add the groups as claims -- be careful if the number of groups is too large
                if (AccountOptions.IncludeWindowsGroups)
                {
                    var wi = wp.Identity as WindowsIdentity;
                    var groups = wi.Groups.Translate(typeof(NTAccount));
                    var roles = groups.Select(x => new Claim(JwtClaimTypes.Role, x.Value));
                    id.AddClaims(roles);
                }

                await HttpContext.SignInAsync(
                    IdentityServer4.IdentityServerConstants.ExternalCookieAuthenticationScheme,
                    new ClaimsPrincipal(id),
                    props);
                return Redirect(props.RedirectUri);
            }
            else
            {
                // trigger windows auth
                // since windows auth don't support the redirect uri,
                // this URL is re-triggered when we call challenge
                return Challenge(AccountOptions.WindowsAuthenticationSchemeName);
            }
        }

Если вы хотите использовать Azure AD, я бы порекомендовал вам прочитать эту статью: https://damienbod.com/2019/05/17/updating-microsoft-account-logins-in-asp-net-core-with-openid-connect-and-azure-active-directory/

0 голосов
/ 12 июня 2019

Один из способов сделать это - развернуть 2 экземпляра приложения. Первый из них настроен на использование аутентификации Windows, а другой использует IS4.

например: yoursite.internal.com

yoursite.com

Ваш локальный DNS должен перенаправлять трафик изнутри с yoursite.com на yoursite.internal.com

yoursite.internal.com будет настроен для использования аутентификации AD. В вашем appsettings.json должен быть флаг, указывающий, является ли этот экземпляр аутентификацией AD или IS4.

Недостатком этого решения является то, что вам нужно развернуть 2 экземпляра

0 голосов
/ 12 июня 2019

Не уверен, что это то, что вам нужно, но я бы использовал Active Directory Federation Services для настройки OAuth2 endpoint и получения токена пользователя в .Net Core Web App.

Не поддерживает NTLM-аутентификациюограничено в браузерах не Microsoft?

OAuth2 имеет преимущество использования только стандартных технологий.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...