Использование учетных записей Windows Domain и учетных записей, управляемых приложениями

Легко создать приложение ASP.NET MVC, которое проверяет подлинность на основе пользователя домена Windows. Также легко создать тот, который использует отдельные учетные записи, хранящиеся с помощью Entity Framework. На самом деле существуют шаблоны проектов для обоих.

Но я хочу использовать типы BOTH типов аутентификации в одном приложении. Я попытался объединить код из обоих шаблонов проектов. У меня проблема в Startup.Auth.cs.

// from "Individual Accounts" template
app.UseCookieAuthentication(new CookieAuthenticationOptions
{
    AuthenticationType = DefaultAuthenticationTypes.ApplicationCookie,
    LoginPath = new PathString("/Account/Login"),
    Provider = new CookieAuthenticationProvider
    {
        OnValidateIdentity = SecurityStampValidator.OnValidateIdentity<ApplicationUserManager, ApplicationUser>(
            validateInterval: TimeSpan.FromMinutes(30),
            regenerateIdentity: (manager, user) => user.GenerateUserIdentityAsync(manager))
    }
});

Существование проверки подлинности cookie для прокси-сервера owin, по-видимому, приводит к тому, что идентификаторы домена становятся не аутентифицированными. Если я выйду из этой строки, работает проверка подлинности домена. Но без этого я не могу поддерживать отдельные учетные записи пользователей.

Я загрузил исходный код проекта katana и изучил CookieAuthenticationHandler.cs, но я не совсем понимаю, как он работает в контексте конвейера OWIN.

Как я могу использовать инфраструктуру идентификации ASP.net, чтобы мое приложение могло аутентифицировать пользователей из домена Windows или хранилища пользовательских приложений?

Ответ 1

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

Это имеет преимущество, опираясь на существующую структуру и стандартную конфигурацию.

Оттуда вы решите либо

создать пользователя AD для каждого пользователя Интернета или
создать пользователя БД/Интернет для каждого пользователя AD.

Создание пользователя Identity для каждого пользователя AD легче реализовать дальше. Тогда такие же файлы cookie и фильтры могут существовать во всем приложении.

В этом случае вы можете

использовать субдомен для вашего приложения
Проект аутентификации AD может иметь исключительную цель аутентификации/авторизации, тогда веб-приложение может представлять остальную часть вашего приложения.

Альтернативно, если вы хотите действительно унифицированное решение, используйте MohammadYounes/Owin-MixedAuth

MohammadYounes/Owin-MixedAuth

Install-Package OWIN-MixedAuth

В Web.config

<location path="MixedAuth">
  <system.webServer>
    <security>
      <authentication>
        <windowsAuthentication enabled="true" />
      </authentication>
    </security>
  </system.webServer>
</location>

В в Startup.Auth.cs

app.UseMixedAuth(cookieOptions);

Как это работает:

Обработчик использует ApplyResponseChallengeAsync для подтверждения запроса 401. Если это так, он перенаправляется на путь обратного вызова для запроса аутентификации из IIS, который настроен на запрос AD.

        AuthenticationResponseChallenge challenge = Helper.LookupChallenge(
              Options.AuthenticationType, Options.AuthenticationMode);

A 401 вызов вызван неавторизованными пользователями, пытающимися использовать ресурс, требующий аутентификации

Обработчик использует InvokeAsync, чтобы проверить, поступает ли запрос от пути обратного вызова (IIS), а затем вызывает AuthenticateCoreAsync

    protected async override System.Threading.Tasks.Task<AuthenticationTicket>
                AuthenticateCoreAsync()
    {
        AuthenticationProperties properties = UnpackStateParameter(Request.Query);

        if (properties != null)
        {
            var logonUserIdentity = Options.Provider.GetLogonUserIdentity(Context);

            if (logonUserIdentity.AuthenticationType != Options.CookieOptions.AuthenticationType
                && logonUserIdentity.IsAuthenticated)
            {
                AddCookieBackIfExists();

                ClaimsIdentity claimsIdentity = new ClaimsIdentity(
                    logonUserIdentity.Claims, Options.SignInAsAuthenticationType);

                //  ExternalLoginInfo GetExternalLoginInfo(AuthenticateResult result)
                claimsIdentity.AddClaim(new Claim(ClaimTypes.NameIdentifier,
                  logonUserIdentity.User.Value, null, Options.AuthenticationType));

                //could grab email from AD and add it to the claims list.
                var ticket = new AuthenticationTicket(claimsIdentity, properties);

                var context = new MixedAuthAuthenticatedContext(
                   Context,
                   claimsIdentity,
                   properties,
                   Options.AccessTokenFormat.Protect(ticket));

                await Options.Provider.Authenticated(context);

                return ticket;
            }
        }
        return new AuthenticationTicket(null, properties);
    }

AuthenticateCoreAsync использует AddCookieBackIfExists для чтения куки файлов претензий, созданных AD, и создает его собственные основанные на претензии.

Пользователям AD предоставлено Cookie на основе требований, идентичное веб-пользователям. AD теперь как и любой другой сторонний аутентификатор (Google, FB, LinkedIN)

Ответ 2

По этой причине я не смог использовать предварительно искушенные решения для аутентификации. В нашем проекте прошедшие годы (и гибкий подход) оставили нам 4 разных способа аутентификации, что раздражает, но мы поддерживаем все устаревшие версии приложений в этой области, поэтому мы должны сохранить все это (по крайней мере пока).

В итоге я создал factory, который определяет механизм аутентификации (через любое из нескольких средств, таких как формат токена, наличие какой-то другой вещи), а затем возвращает оболочку, которая несет логику для проверки этого метода аутентификации и настройки директор.

Это запускается в настраиваемом модуле HTTP, так что главный пользователь будет создан и аутентифицирован до того, как запрос поступит в контроллер. Думаю, в вашем случае окна Auth станут последним резервом. В нашем приложении Web API мы использовали тот же подход, но с помощью обработчика делегирования вместо HTTP-модуля. Вы можете сказать, что это тип локальной федерации токенов. Текущая реализация позволяет нам добавлять или изменять любую процедуру проверки или добавлять любой другой формат токена; в конце концов, пользователь получает правильную идентификацию или получает отказ. Выполнено всего несколько дней.

Ответ 3

Мне кажется, лучшим ответом на этот вопрос является использование инфраструктуры аутентификации и авторизации. Есть много вариантов (как коммерческих, так и бесплатных). Вы могли бы, конечно, написать свое, но я бы отговорил его. Многие очень умные люди ошибаются.

Я бы посмотрел IdentityServer3. Это, конечно, не единственное решение, но его довольно хорошая система проверки подлинности и авторизации. Это с открытым исходным кодом и довольно легко встает и работает в спешке. Ваш вариант использования является общим, и вы найдете очень полезную информацию по ссылке выше. Чистое разделение между авторизацией и аутентификацией, варианты социальной аутентификации, удобство работы с токенами json, которые инкапсулируют запросы пользователей и т.д.

Как это может помочь вам

IdentityServer3 позволяет вам настроить Identity Providers для проверки подлинности и есть много точек расширения, которые позволят вам реализовать цепочку ответственности, которая может обрабатывать оба ваших сценария. Из docs:

IdentityServer поддерживает аутентификацию с использованием внешних поставщиков удостоверений. Внешний механизм аутентификации должен быть инкапсулирован в промежуточное ПО аутентификации Katana.

Сама Katana поставляется с промежуточным программным обеспечением для Google, Facebook, Twitter, учетных записей Microsoft, WS-Federation и OpenID Connect, но есть также сообщества, разработанные middlewares (включая Yahoo, LinkedIn и SAML2p).

Чтобы настроить промежуточное программное обеспечение для внешних поставщиков, добавьте метод в проект, который принимает IAppBuilder и строку в качестве параметров.

IdentityServer3 поддерживает AD как поставщик идентификации через окно входа в браузер и будет поддерживать более программную реализацию с помощью пользовательского гранта. Вы также можете посмотреть здесь для получения дополнительной информации об аутентификации IdentityServer3 и AD.

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

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

При правильной конфигурации IdentityServer3 может удовлетворить ваши требования. Вам нужно будет реализовать своих собственных поставщиков проверки подлинности и подключить их к инфраструктуре, но это не так уж и много, чем это. Что касается авторизации, там есть много вариантов.