Перейти к основному содержимому

Приложения по SAML и RS256

Актуально для: identity 0.27 · Проверено: 26.09.2026

Identity — провайдер входа для приложений организации. Большинство из них говорит на OpenID Connect, но есть два частых исключения, и оба закрыты:

  • приложение умеет только SAML 2.0 (старые вики, трекеры, коробочные системы);
  • OIDC-приложение, чья библиотека проверяет только подпись RS256.

Человек в обоих случаях видит обычную страницу входа identity: пароль, второй фактор, ключи доступа, вход через корпоративный провайдер — всё как для остальных приложений.

OIDC-приложение, которому нужен RS256​

По умолчанию identity подписывает ID-токены алгоритмом EdDSA. Рядом с этим ключом живёт ключ RSA-2048, он опубликован в JWKS (/oauth/jwks, kty: RSA) и указан в discovery. Чтобы приложение получало ID-токен с подписью RS256, в консоли identity, Приложения → Изменить, задайте в options:

{ "id_token_alg": "RS256" }

Access-токены по-прежнему подписываются EdDSA — их читает только сам identity.

Приложение по SAML​

Поддерживается вход, начатый в приложении (SP-initiated Web SSO), привязки HTTP-Redirect и HTTP-POST.

  1. Дайте приложению метаданные identity:

    https://<адрес identity>/saml/metadata

    В них entity ID identity (https://<адрес identity>/saml), адрес входа /saml/sso и сертификат подписи. Если приложение не умеет читать метаданные по адресу, перенесите эти три значения вручную.

  2. Зарегистрируйте приложение в консоли identity, Приложения → Приложения SAML → Создать:

    ПолеЧто это
    entity_identity ID приложения — из его настроек или метаданных
    nameназвание, которое человек увидит на странице входа
    acs_urlsадреса Assertion Consumer Service; ответ уходит только на них, адрес сверяется точно
    nameidчем назвать человека: username (имя учётной записи) или email
    attributesпередавать ли атрибуты username, email, displayName, groups

  3. Проверьте вход: откройте приложение и нажмите в нём «Войти через SSO».

Утверждение подписано (и ответ целиком тоже): RSA-SHA256, дайджест SHA-256, каноникализация Exclusive C14N. В нём аудитория — entity ID приложения, получатель — адрес ACS, ссылка на запрос приложения и окно действия пять минут. groups — идентификаторы групп identity, как в OIDC.

Чего нет
  • Вход, начатый в identity (IdP-initiated), отклоняется намеренно: это схема, с которой начинаются атаки подделки входа. Вход всегда начинается в приложении.
  • Подпись запроса приложения не проверяется. Запрос привязан к приложению регистрацией и точным адресом ACS — ответ никуда больше не уйдёт.
  • Нет единого выхода (Single Logout), шифрования утверждений и импорта метаданных приложения.

Если в nameid выбран email, а у учётной записи нет адреса, приложение получит отказ InvalidNameIDPolicy. Каждый вход и отказ пишется в журнал аудита identity: saml.sso, изменения реестра — saml.sp.put и saml.sp.delete.

Ротация ключей​

Ротация (POST /control/oidc/keys/rotate) меняет оба ключа сразу — EdDSA и RSA. Старый сертификат остаётся в метаданных, пока действуют выданные им токены, поэтому приложение, которое перечитывает метаданные, переходит на новый сам. Приложению, в которое сертификат вставлен вручную, после ротации нужно вставить новый.

На установке с сертифицированной криптографией ГОСТ ключа RSA нет: RS256 и SAML там недоступны, и консоль скажет об этом при регистрации.