Блог

Я заменяю нашу собственную службу аутентификации на Okta и нуждаюсь в поддержке единого входа с помощью Saml2 в нашем приложении. Okta можно настроить как поставщика услуг, отправлять SAMLRequest , получать и проверять SAMLResponse . Пока все хорошо: я смог настроить поставщика удостоверений в Okta, получить утверждение, и, согласно журналам, утверждение было успешно проверено, и пользователь автоматически предоставил.

Но что происходит дальше?

1. В потоке, инициированном Idp, как я могу перенаправить пользователя на URL-адрес приложения? RelayState Настроен ли Idp только для опции? Мне не нравится идея, что всем нашим клиентам придется вносить изменения, если мы изменим URL нашего приложения. Я бы ожидал возможности связать Idp с приложением Okta, поэтому URL-адрес перенаправления будет настроен этим приложением.
2. После перенаправления на сайт нашего приложения, как мне аутентифицировать пользователя в Asp.Net Ядро? Я реализовал обычай AuthenticationHandler , который считывает sid cookie, установленный Okta при перенаправлении, и извлекает информацию о сеансе из Okta. Оттуда я получаю имя пользователя и создаю Principal . Этот подход работает, но мне кажется неправильным — он слишком ручной, я бы ожидал Okta.Sdk, чтобы сделать это для меня (если это правильный способ аутентификации).
3. После успешной проверки утверждения возможно ли обменять токен saml на токен OAuth для аутентификации в приложении?

Ответы на ваши вопросы, основанные на чистом подходе SAML:

1. Вы можете использовать единый вход, инициированный SP — вы достигнете той же цели — попасть на какую-либо страницу. Допустим, ваше приложение, действующее в качестве поставщика услуг SAML, находится по my.app.com адресу, и вы хотите, чтобы пользователи заходили на https://my.app.com/foo/bar сайт после их аутентификации. Публикация https://my.app.com/foo/bar для ваших клиентов / пользователей приведет к запуску потока SP-init, когда они в конечном итоге перейдут по этой ссылке. После некоторого обмена сообщениями между IdP и SP пользователь будет выбран в https://my.app.com/foo/bar качестве конечного пункта назначения.

Вы можете реализовать ту же идею с потоком, инициируемым IdP, с помощью дополнительного перенаправления в вашем приложении или выше по течению вашего приложения в вашем стеке. Это иногда называют URL-адресом тщеславия. Например, если URL—адрес тщеславия https://my.app.com/home Таким образом, ваше приложение или другой вышестоящий компонент могут преобразовать этот URL-адрес в другой, целевой URL-адрес и перенаправить его на целевой. Целевой URL-адрес может запускать поток, инициированный IdP, с помощью RelayState или поток, инициированный SP, как описано выше. Ваше приложение или вышестоящий компонент должны поддерживать сопоставление между тщеславием и целевыми URL-адресами.

2. Вы хотите, чтобы Okta был вашим поставщиком идентификационных данных SAML, а ваше приложение — поставщиком услуг SAML. Вы попробовали этот обходной путь на основе файлов cookie, потому что не понимали, как реализовать SAML в вашем .СЕТЕВОЕ приложение.

Okta не предоставляет инструментарий SAML или SDK для .NET apps, выступающие в качестве поставщиков услуг SAML, рекомендуют сторонние библиотеки. ASP.NET не поддерживает SAML из коробки … что является еще одной причиной, по которой Okta рекомендует сторонние приложения. (Microsoft не является одной из этих сторонних сторон). Два популярных, бесплатных и широко используемых варианта — это Sustainsys и ITFoxTec. Взгляните на их документы, выберите один и внедрите его. После этого вам не придется прибегать к обходному пути использования файлов cookie.

3. После того, как ваше приложение обработает ответ SAML и сгенерирует ответ (если таковой имеется), выполняется этап аутентификации и становится известна личность участника. Теперь ваше приложение может делать все, что вы хотите, в качестве следующего шага, включая получение токена OAuth. Этот следующий шаг не является частью протокола SAML … если только это не новый / новый поток SAML, то есть.

Ответы на ваши вопросы основаны на подходе, при котором вы используете Okta в качестве поставщика услуг SAML и хранилища идентификационных данных с другим поставщиком идентификационных данных SAML. Поток составляет 2 перехода: SAML IdP -> Okta как SAML SP -> ваше приложение.

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

1. Ваше приложение будет «вызвано» через RelayState, если Okta перенаправит на URL-адрес в RelayState после обработки ответа SAML с первого перехода. Если вы сделаете свой RelayState равным https://my.app.com/foo/bar , то после некоторого обмена данными между IdP и SP и вашим приложением пользователь попадет в https://my.app.com/foo/bar качестве конечного пункта назначения. Ваше приложение должно будет запустить эту последовательность, активировав 1-й переход через поток SAML, инициированный IdP или SP.

2. В интерфейсном стиле интеграции с обратным вызовом вы будете использовать Microsoft interfaces библиотеки Okta, как показано в примере Okta.

3. Используя Okta в качестве хранилища идентификационных данных и аутентифицированного участника, вы можете получать токены от Okta с помощью дополнительных шагов. Если ваша цель — включить вызовы API в ваше приложение от третьей стороны через Okta, изучите стиль интеграции обратного вызова API.

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

1. Сначала настройте Okta вашей организации как Saml Sp для внешнего Saml IdP. Документация по Api находится здесь. Инструкции пользовательского интерфейса здесь. Вы должны получить информацию для SAML PROTOCOL SETTINGS (URI IdP-эмитента, URL-адрес единого входа IdP и сертификат подписи IdP) от вашего внешнего IdP.

2. Следующий шаг — создание веб-приложения в Okta. Вы Login redirect URIs должны закончить с /authorization-code/callback , иначе вам придется настроить его в CallbackPath свойстве в коде (см. Ниже). Вам не нужно реализовывать эту конечную точку, фреймворк сделает это за вас.

3. Теперь установите Okta.AspNetCore nuget и добавьте этот код в ConfigureServices метод

     services.AddAuthentication(options =>
    {
        options.DefaultAuthenticateScheme = CookieAuthenticationDefaults.AuthenticationScheme;
        options.DefaultSignInScheme = CookieAuthenticationDefaults.AuthenticationScheme;
        options.DefaultChallengeScheme = OktaDefaults.MvcAuthenticationScheme;
    })
    .AddCookie()
    .AddOktaMvc(new OktaMvcOptions
    {
        OktaDomain = "<okta_domain>",
        ClientId = "<app_client_id>",
        ClientSecret = "<app_client_secret>",
        Scope = OktaDefaults.Scope,
        //CallbackPath = "/authorization-code/callback" <= it's default value, change it if required
    });
     

Вы найдете app_client_id и app_client_secret внизу вкладки «Общие» веб-приложения, созданного на шаге 2.

4. Теперь самая интересная часть. Если вы хотите запустить процесс аутентификации для внутренних пользователей (а не для внешних пользователей Saml Idp), вы вызываете ChallengeAsync метод. Что-то вроде этого:

     [ApiController]
    [Route("[controller]")]
    public class AuthController : ControllerBase
    {
        [HttpGet("login")]
        public async Task Login()
        {
            var properties = new AuthenticationProperties
            {
                RedirectUri = "/"
            };
   
            await HttpContext.ChallengeAsync(properties);
        }
    }
     

Всякий раз, когда вы нажимаете /auth/login url, вы будете перенаправлены на Okta для аутентификации.

Если вы хотите запустить процесс аутентификации для внешних пользователей Idp, вы должны добавить idp параметр в AuthenticationProperties class.

 [ApiController]
[Route("[controller]")]
public class SsoController : ControllerBase
{
    private readonly ILogger<SsoController> _logger;

    private readonly IOktaClient _oktaClient;

    public SsoController(ILogger<SsoController> logger, IOktaClient oktaClient)
    {
        _logger = logger;
        _oktaClient = oktaClient;
    }

    [HttpGet]
    public async Task Sso([FromQuery] string name)
    {
        var idpProviders = await _oktaClient.IdentityProviders.ListIdentityProviders(q: name, limit: 1).ToListAsync();

        // search is case insensitive and "starts with", and not "exact match"
        var idp = idpProviders.FirstOrDefault(p => p.Name.Equals(name, StringComparison.InvariantCultureIgnoreCase));

        if (idp == null)
        {
            _logger.LogWarning($"idp name '{name}' doesn't exist");

            var authenticationProperties = new AuthenticationProperties
            {
                RedirectUri = "/"
            };

            await HttpContext.ForbidAsync(authenticationProperties);
        }
        else
        {
            var properties = new AuthenticationProperties
            {
                RedirectUri = "/",
                Items = { ["idp"] = idp.Id }
            };
            await HttpContext.ChallengeAsync(properties);
        }
    }
}
  

Когда вы нажмете /sso?name=MySamlIdp url, вы будете искать MySamlIdp поставщика удостоверений, определенного на шаге 1, и использовать его идентификатор, чтобы сообщить Okta, куда перенаправить пользователя для аутентификации. IOktaClient Определено в Okta.Sdk nuget.