Как сказал @Tratcher, параметр AuthenticationType используется Microsoft.Owin.Security в качестве ключа для поиска экземпляров промежуточного ПО для аутентификации.

В приведенном ниже коде будет использоваться следующий простой вспомогательный метод, чтобы требовать аутентификации всех запросов. На практике вы с большей вероятностью будете использовать атрибут [Authorize] на чувствительных контроллерах, но мне нужен пример, который не зависит от каких-либо фреймворков:

private static void AuthenticateAllRequests(IAppBuilder app, params string[] authenticationTypes)
{
    app.Use((context, continuation) =>
    {
        if (context.Authentication.User != null &&
            context.Authentication.User.Identity != null &&
            context.Authentication.User.Identity.IsAuthenticated)
        {
            return continuation();
        }
        else
        {
            context.Authentication.Challenge(authenticationTypes);
            return Task.Delay(0);
        }
    });
}

Вызов context.Authentication.Challenge(authenticationTypes) вызовет проверку подлинности каждого из предоставленных типов проверки подлинности. Мы просто собираемся предоставить один, наш тип аутентификации WS-Federation.

Правильный код

Итак, во-первых, вот пример «оптимальной» конфигурации запуска Owin для сайта, который просто использует WS-Federation, как и вы:

public void Configuration(IAppBuilder app)
{
    app.SetDefaultSignInAsAuthenticationType(CookieAuthenticationDefaults.AuthenticationType);

    app.UseCookieAuthentication(new CookieAuthenticationOptions());

    app.UseWsFederationAuthentication(new WsFederationAuthenticationOptions
    {
        AuthenticationType = "WS-Fed Auth (Primary)",
        Wtrealm = ConfigurationManager.AppSettings["app:URI"],
        MetadataAddress = ConfigurationManager.AppSettings["wsFederation:MetadataEndpoint"]
    });

    AuthenticateAllRequests(app, "WS-Fed Auth (Primary)");

    app.UseWelcomePage();
}

Обратите внимание на использование "WS-Fed Auth (Primary)" AuthenticationType для уникальной идентификации экземпляра промежуточного программного обеспечения WS-Federation, который мы настроили. Это означает, что вы могли бы, например, использовать "WS-Fed Auth (Secondary)" с отдельным сервером WS-Federation в качестве запасного варианта, если бы у вас было такое требование.

Эта конфигурация будет делать следующее:

1. Сначала сообщите конвейеру безопасности Owin, что по умолчанию мы хотим аутентифицировать запросы с значением CookeAuthentication AthenticationType по умолчанию. (Это просто постоянная строка в этом классе CookieAuthenticationDefaults, и это значение по умолчанию, используемое свойством CookieAuthenticationOptions.AuthenticationType.)
2. Затем зарегистрируйте экземпляр промежуточного программного обеспечения для проверки подлинности файлов cookie со всеми параметрами по умолчанию, чтобы он соответствовал ключу AuthenticationType, который мы установили по умолчанию на шаге 1.
3. Затем зарегистрируйте экземпляр промежуточного программного обеспечения проверки подлинности WS-Federation с параметрами, которые мы определяем в файле Web.config, и с настраиваемым значением AuthenticationType, чтобы мы могли обратиться к нему позже.
4. После того, как все регистрации промежуточного программного обеспечения аутентификации выполнены, мы говорим конвейеру аутентифицировать все запросы (с помощью нашего специального вспомогательного метода, который вызывает Microsoft.Owin.Security методы для выдачи вызовов любому неаутентифицированному запросу)
5. Наконец, если пользователь прошел аутентификацию, покажите страницу приветствия!

Неверный код

Так что здесь есть несколько способов ошибиться.

Не указан тип аутентификации по умолчанию

Чтобы поэкспериментировать, я попробовал сделать это, и вы сразу поймете, в чем проблема:

public void Configuration(IAppBuilder app)
{
    var x = app.GetDefaultSignInAsAuthenticationType();

    app.SetDefaultSignInAsAuthenticationType(x);
}

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

«Значение по умолчанию для SignInAsAuthenticationType не найдено в свойствах IAppBuilder. Это может произойти, если промежуточное ПО для проверки подлинности добавлено в неправильном порядке или если оно отсутствует».

Верно - потому что по умолчанию конвейер Microsoft.Owin.Security ничего не предполагает о промежуточном программном обеспечении, которое вы собираетесь использовать (т.е. Microsoft.Owin.Security.Cookies даже не известно о его наличии), поэтому он не знает, что должно быть по умолчанию.

Использование неправильного типа аутентификации по умолчанию

Сегодня это стоило мне много времени, потому что я толком не знал, что делаю:

public void Configuration(IAppBuilder app)
{
    app.SetDefaultSignInAsAuthenticationType("WS-Fed AAD Auth");

    // ... remainder of configuration
}

Итак, он будет продолжать попытки аутентифицировать вызывающего с помощью WS-Federation при каждом вызове. Дело не в том, что это сверхдорогие, а в том, что промежуточное ПО WS-Federation на самом деле создает проблемы на каждый запрос. Таким образом, вы никогда не сможете войти, и вы видите, как множество URL-адресов для входа пролетает мимо вас. :П

Возможности

Итак, что здорово иметь всю эту гибкость в конвейере, так это то, что вы можете делать действительно классные вещи. Например, у меня есть домен с двумя разными веб-приложениями внутри него, работающими с разными подпутьями, такими как: example.com/foo и example.com/bar. Вы можете использовать функцию сопоставления Owin (как в app.Map(...)), чтобы настроить совершенно другой конвейер аутентификации для каждого из этих приложений. В моем случае один использует WS-Federation, а другой - клиентские сертификаты. Было бы ужасно пытаться сделать это в монолитном System.Web фреймворке. :П