Документация/Настройка SSO/Okta (OIDC)

Настройка Okta (OIDC)

Пошаговое руководство по настройке единого входа с Okta с использованием OpenID Connect.

Предварительные условия

  • Admin-учётная запись Okta
  • Учётная запись администратора организации SecureCodingHub

Шаг 1 — Создайте приложение Okta

1

Перейдите в Okta Admin ConsoleApplicationsCreate App Integration

2

Sign-in method: OIDC

3

Application type: Web Application

4

App name: SecureCodingHub

5

Sign-in redirect URI: https://api.limeplate.com/api/sch/auth/sso/callback/oidc

6

Assignments: Назначьте Вашим пользователям/группам

Шаг 2 — Скопируйте учётные данные

Соберите следующие значения из Вашего приложения Okta:

НастройкаГде найти
Client IDGeneral → Client Credentials
Client SecretGeneral → Client Credentials
Okta DomainВаш URL Okta (например, dev-12345.okta.com)
Discovery URLhttps://{okta-domain}/.well-known/openid-configuration

Шаг 3 — Настройте SSO в SecureCodingHub

1

Войдите как Администратор организации → Настройки SSO

2

Протокол: OIDC

3

Entity ID / Client ID: вставьте Ваш Okta Client ID

4

Discovery / Metadata URL: вставьте Ваш Okta OpenID configuration URL

5

Client Secret: вставьте секрет

6

Включите SSO

7

Нажмите Сохранить

app.securecodinghub.com/organization/sso
Единый вход
Аутентифицируйте учащихся через Вашего поставщика идентификации.
OIDC
OpenID Connect — рекомендуется
SAML
Федерация SAML 2.0
0oa1b2c3d4e5f6g7h8i9
https://dev-12345.okta.com/.well-known/openid-configuration
••••••••••••••••
SSO включён

Шаг 4 — Протестируйте

1

Откройте окно браузера в режиме incognito/private

2

Перейдите к входу SecureCodingHub

3

Введите email-адрес с доменом Вашей организации

4

Вы должны быть перенаправлены к входу Okta

5

После аутентификации Вы должны быть вошедшим в SecureCodingHub

Совет: Если Вы используете группы Okta, Вы можете назначить приложение SecureCodingHub группе, чтобы все участники получили доступ автоматически. В сочетании с JIT-провижинингом, новые участники группы создаются в SecureCodingHub при первом входе.

Распространённые ловушки Okta SAML

Хотя это руководство фокусируется на OIDC, многие тенанты Okta запускают SecureCodingHub поверх SAML, и повторяются те же проблемы, специфичные для Okta. Первая — несоответствие Audience URI. Okta называет это поле Audience URI (SP Entity ID) в General Settings SAML, и значение должно точно соответствовать тому, что SecureCodingHub публикует как свой entity ID. Распространённая ошибка — ввести URL веб-сайта SecureCodingHub, а не API entity ID. Проверьте значение против поля SP Entity ID на странице настроек SSO SecureCodingHub перед сохранением приложения Okta.

Вторая ловушка — политика входа в приложение Okta. Okta применяет политику на уровне приложения, которая может требовать дополнительные факторы, ограничивать по сетевой зоне или полностью отказывать в доступе на основе членства в группе. Если конечный пользователь сообщает, что SSO перенаправляет их в Okta и затем отскакивает обратно с ошибкой access-denied, причина почти всегда — правило политики входа в приложение, не соответствующее пользователю. Проверьте Sign On Policy в приложении и подтвердите правило, применяющееся к тестовому пользователю. Третья распространённая ловушка — несоответствие формата Name ID. Okta по умолчанию использует Unspecified, но SecureCodingHub ожидает формат emailAddress. Установите формат Name ID на EmailAddress в настройках приложения и подтвердите, что source-атрибут — это user.email или user.login.

Как проверить, что SSO работает от начала до конца

Проверка начинается в incognito-сессии браузера, чтобы избежать любых cookie от предыдущих входов. Перейдите на страницу входа SecureCodingHub, введите корпоративный email-адрес с Вашим верифицированным доменом и подтвердите, что браузер перенаправляет на Ваш тенант Okta. После аутентификации в Okta перенаправление должно привести Вас в SecureCodingHub на панель для правильной организации. Если Вы приземляетесь на общую посадочную страницу или 404, наиболее вероятная причина в том, что пользователь ещё не существует в SecureCodingHub, а JIT-провижининг отключён или отклонил событие create.

Во-вторых, проверьте назначение роли и места. JIT-провизионированные пользователи всегда приземляются с ролью learner — SecureCodingHub сегодня не читает информацию о роли из group claims Okta, поэтому повышение до org_admin должно выполняться из админ-интерфейса SecureCodingHub после того, как пользователь существует. В-третьих, выйдите, затем войдите снова. Второй вход должен быть почти тихим благодаря cookie сессии Okta. Если второй вход принуждает к полной повторной аутентификации, срок жизни сессии Okta установлен слишком коротким для нормального использования; отрегулируйте глобальную политику сессии или политику входа в приложение соответственно. Для деталей на уровне протокола см. Руководство по настройке SAML.