Ошибка, когда проверка подписи с усилением электронной подписи не удалась или еще недоступна

Обновлено: 04.07.2024

Распространенные проблемы и решения, с которыми вы можете столкнуться при настройке системы единого входа в Диспетчере API, а также как включить трассировку для единого входа.

Вход в систему как администратор и пользователь SSO

Диспетчер API не работает должным образом при входе в систему как администратора, так и пользователя системы единого входа.

Если администратор хочет войти в Диспетчер API и как администратор API, и как пользователь системы единого входа, рекомендуется, чтобы он использовал для этого разные браузеры. Использование отдельных вкладок в одном и том же браузере недостаточно, так как вкладки используют один и тот же сеанс.

Не удается получить доступ к Диспетчеру API после успешного входа

Вы не можете получить доступ к Диспетчеру API после успешного входа с помощью системы единого входа.

Убедитесь, что в файле журнала агента единого входа нет ошибок из-за неправильной настройки. Кроме того, убедитесь, что вы обращаетесь к Диспетчеру API, используя то же имя хоста или IP-адрес, которые указаны в метаданных IdP Диспетчера API (файл idp.xml), используемых поставщиком удостоверений:

Сайт IdP недоступен

Вы пытаетесь войти в API Manager с помощью системы единого входа, и в вашем браузере появляется следующее сообщение:

В этом случае поставщик удостоверений (например, Shibboleth, KeyCloak, службы федерации Active Directory и т. д.) либо не работает, либо недоступен. Обратитесь за поддержкой к системному администратору. Системный администратор должен убедиться, что служба работает и что нет ограничений брандмауэра, препятствующих доступу к службе.

Внутренняя ошибка, если часы API Gateway и IdP не синхронизированы

При попытке войти в Диспетчер API с помощью системы единого входа возникает внутренняя ошибка, если часы вашего сервера API Gateway и вашего сервера IdP не синхронизированы должным образом.

Чтобы подтвердить причину ошибки, проверьте файл трассировки:

Убедитесь, что время на сервере шлюза API синхронизировано с IdP.

Тайм-аут ответа LDAP при входе

При попытке войти в Диспетчер API с помощью системы единого входа появляется сообщение, подобное следующему:

Это связано с проблемой между IdP и службой LDAP. Обратитесь к сетевому администратору.

Ошибка неверного пользователя или пароля после успешного входа

При попытке войти в Диспетчер API с помощью системы единого входа появляется следующее сообщение:

Чтобы подтвердить причину ошибки, проверьте файл трассировки:

В этом сценарии вы успешно вошли в систему с помощью единого входа, но организация, связанная с вашим входом, не настроена. Либо организация неправильно настроена в файле service-provider.xml, либо организация не существует в диспетчере API.

Следующее сообщение появляется на странице браузера, если организация не существует в диспетчере API:

Убедитесь, что организация правильно настроена в файле service.provider.xml и существует в диспетчере API.

Например, файл service-provider.xml содержит следующий раздел FilterMapping:

В этом примере организация называется Research .

Войдите в API Manager как пользователь apiadmin (используя URL-адрес для входа без единого входа) и выберите «Реестр клиентов» > «Организации». Если организация под названием Research не существует, вы должны добавить ее.

У поставщика услуг нет действительного сертификата

Эта внутренняя ошибка сервера возникает, когда псевдоним, определенный атрибутом keyAlias (находится в элементе ServiceProvider в файле service-provider.xml), не может быть найден в файле хранилища ключей.

Ошибка выхода из Shibboleth IdP

Вы используете Shibboleth в качестве поставщика удостоверений, и попытка выхода завершается с ошибкой с сообщением, подобным следующему:

Установите следующие параметры для вашего IDP Shibboleth (как подробно описано в примере файла INSTALL_DIR/apigateway/samples/sso/ShibbolethIDP/conf/idp.properties.forlogout):

Проблемы выхода из службы федерации Active Directory

Если вашим SAML IDP являются службы федерации Active Directory (AD FS), у вас могут возникнуть проблемы с выходом из системы единого входа.

Вы должны добавить правило утверждения, чтобы разрешить выход из системы SSO:

В разделе управления AD FS выберите "Отношения доверия" > "Доверия с проверяющей стороной" > "Изменить правила утверждений" и выберите "Добавить правило".

Установите тип шаблона правила утверждения для отправки утверждений с использованием пользовательского правила.

Назовите правило утверждения и добавьте следующее правило:

Замените именем вашего доверия с проверяющей стороной SAML и значением вашего идентификатора службы федерации. Чтобы получить значение идентификатора службы федерации, щелкните AD FS > Изменить свойства службы федерации.

Ошибка проверки подписи

Трассировка шлюза API содержит текст:

Рассмотрите возможность добавления атрибута формата (как описано в тексте трассировки) в тег SamlIdentityProvider в файле service-provider.xml.

Убедитесь, что вы перезапустили API Gateway после сохранения файла.

Проверка утверждения SAML не проходит

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

Если подробная трассировка показывает, что проверка не удалась из-за истечения срока действия утверждения SAML, существует конфликт серверного времени между сервером IdP и шлюзом API, и срок действия утверждения SAML считается просроченным.

Синхронизируйте время сервера IdP со шлюзом API. В Linux убедитесь, что служба NTP запущена.

Кроме того, откройте файл service-provider.xml в разделе SamlIdentityProvider, задайте для параметра verifyAssertionExpiration значение false , сохраните и повторно разверните файл service-provider.xml на шлюзе API.

После устранения проблемы отключите трассировку для единого входа и перезапустите шлюз API.

Неверный запросчик на странице Keycloak

На стороне IdP в Events может быть обнаружено следующее событие LOGIN_ERROR:

Ключ в sso.jks и открытый ключ, хранящийся в ключах SAML Keycloak для приложения, не совпадают как пара ключей. Проверьте ключи SAML в клиенте IdP и импортируйте правильный сертификат.

Страница входа в диспетчер API не отображается

Если не удается загрузить страницу входа в Диспетчер API, а в файле трассировки экземпляра регистрируется исключение NullPointerException следующим образом:

Ошибка при подписании утверждений

После того, как пользователь вводит учетные данные на странице Keycloak, появляется следующая ошибка:

Настройка Sign Assertions в Keycloak отключена. Убедитесь, что эта настройка включена.

Keycloak не может аутентифицировать пользователя

После того, как пользователь вводит учетные данные на странице Keycloak, Keycloak не может аутентифицировать пользователя с сообщением, подобным следующему:

Имя пользователя G-fb7c839b-a879-4231-bae9-1c05e3ba6f04 не соответствует реальному имени пользователя, поскольку ответ SAML анализируется неправильно. Это происходит потому, что сопоставления не настроены в IdP. Убедитесь, что сопоставления установлены правильно в Keycloak. Ниже показан пример сопоставления в Keycloak:

Ошибка получения метаданных

При использовании параметра для указания поставщика удостоверений по URL-адресу диспетчер API при запуске пытается загрузить необходимую информацию о метаданных поставщика удостоверений с заданного URL-адреса метаданных. Это может привести к сбою, если сертификат сервера не может быть проверен с сообщением об ошибке, например:

Чтобы избежать этой ошибки, вы должны добавить полную цепочку сертификатов сервера SamlIdentityProvider:metadataUrl в хранилище доверенных сертификатов, указанное в файле service-provider.xml.

Включить трассировку для единого входа

Чтобы включить трассировку для SSO, измените уровень журнала для регистратора org.opensaml и регистратора io.axway в файле INSTALL_DIR/apigateway/system/conf/log4j2.yaml на отладку:

Вы также должны активировать трассировку в конфигурации шлюза API в Policy Studio:

Перейдите в раздел Конфигурация среды > Настройки сервера в дереве Policy Studio.
Нажмите «Общие» и выберите уровень DEBUG в поле «Уровень трассировки».
Разверните изменения.

Наконец, необходимо перезапустить экземпляр шлюза API, чтобы применить изменения в log4j2.yaml.

После того, как SSO заработает, отключите уровень отладки, изменив уровни трассировки для SSO и OpenSAML обратно на уровни по умолчанию, error и info соответственно, и перезапустите шлюз.

При разработке кода, реализующего Signature Version 4, вы можете получать ошибки от продуктов AWS, с которыми вы тестируете. Ошибки обычно возникают из-за ошибки канонизации запроса, неправильного получения или использования ключа подписи или сбоя проверки параметров подписи, отправленных вместе с запросом.

Ошибки

Устранение ошибок канонизации

Рассмотрите следующий запрос:

Если вы неправильно вычислите канонический запрос или строку для подписи, шаг проверки подписи, выполняемый службой, завершится ошибкой. Следующий пример представляет собой типичный ответ об ошибке, который включает каноническую строку и строку для подписи, вычисленную службой. Вы можете устранить ошибку вычисления, сравнив возвращенные строки с канонической строкой и рассчитанной строкой со знаком.

Устранение ошибок области учетных данных

Продукты AWS проверяют учетные данные для надлежащей области действия; параметр учетных данных должен указывать правильную службу, регион и дату. Например, следующие учетные данные ссылаются на службу Amazon RDS:

Если вы используете те же учетные данные для отправки запроса в IAM, вы получите следующий ответ об ошибке:

В учетных данных также должен быть указан правильный регион.Например, следующие учетные данные для запроса IAM неверно указывают регион Запад США (Северная Калифорния).

Если вы используете учетные данные для отправки запроса в IAM, который принимает только спецификацию региона us-east-1, вы получите следующий ответ:

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

Учетные данные также должны указывать правильный регион для службы и действия в вашем запросе.

Дата, которую вы используете как часть учетных данных, должна совпадать со значением даты в заголовке x-amz-date. Например, следующее значение заголовка x-amz-date не соответствует значению даты, используемому в параметре Credential, следующем за ним.

Если вы используете это сочетание заголовка x-amz-date и учетных данных, вы получите следующий ответ об ошибке:

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

Устранение ошибок подписи ключей

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

Секретный ключ доступа не соответствует идентификатору ключа доступа, который вы указали в параметре Credential.

Возникла проблема с кодом создания ключа.

Чтобы проверить, соответствует ли секретный ключ идентификатору ключа доступа, вы можете использовать свой секретный ключ и идентификатор ключа доступа с известной работающей реализацией. Один из способов — использовать один из AWS SDK для написания программы, которая отправляет простой запрос в AWS, используя идентификатор ключа доступа и секретный ключ доступа, которые вы хотите использовать.

Чтобы проверить правильность вашего кода вывода ключа, вы можете сравнить его с нашим примером кода вывода. Дополнительные сведения см. в разделе Примеры получения ключа подписи для подписи версии 4.

Читайте также: