Блог

Интеграция одного из моих приложений с единым входом в SAML 2.0. Для этого используется поставщик Okta. Я дошел до того, что после успешной аутентификации в okta получаю «токен ответа SAML в кодировке base64» и перенаправляюсь обратно в свое приложение. В этом токене я вижу все данные пользователя, которые мне нужны, но здесь возникает мой вопрос. Нужно ли мне проверять этот ответ в дальнейшем или я должен просто доверять тому, что получаю? Учитывая, что этот токен также содержит signarure?

Моя идея для обеспечения безопасности состояла бы в том, чтобы снова связаться с Okta и проверить, действительно ли это было выдано Okta. Не уверен, что это вообще возможно.

Использование NodeJS для проверки.

Если под токеном ответа SAML вы подразумеваете samlp:Response выданный в соответствии с профилем единого входа, переданным веб-браузером, тогда ответ содержит утверждение, и утверждение подписывается поставщиком удостоверений (кроме того, весь ответ также может быть подписан).

Существует критическое требование безопасности, чтобы всегда проверять подпись ответа. Это упоминается в спецификациях SAML, раздел 4.1.4.3

Причина этого заключается в следующем: в профиле единого входа веб-браузера поставщик удостоверений возвращает токен на веб-странице, которая содержит простую форму с SAMLResponse RelayState полями и и немного кода, который просто автоматически отправляет эту форму в ваше приложение. Технически это означает, что в течение короткого времени токен контролируется веб-браузером пользователя, и именно здесь токен может быть изменен (или подделан).

Таким образом, безопасность протокола в значительной степени зависит от целостности токена, которая достигается с помощью криптографической подписи — это просто обычная старая подпись XMLDSig, применяемая к SAML.

Ваша цель, как получателя токена, состоит не только в проверке подписи, но и в проверке сертификата подписи и сравнении его с сертификатом, который вы ожидаете от доверенного поставщика (или списка сертификатов доверенных поставщиков).

Пропуск этого шага делает ваше приложение уязвимым:

• пропуск проверки означает, что пользователи могут изменять утверждения токена (добавлять / создавать / удалять) к утверждению, проверка подписи завершится неудачей, но вы ее пропустите
• пропуск сопоставления сертификата с известным сертификатом означает, что пользователи могут подделывать свои собственные утверждения, подписывать их с помощью фиктивного сертификата и предоставлять вашему приложению. Этап проверки подписи будет выполнен успешно, но вы не будете знать, что для подписи утверждения использовался фиктивный сертификат

Если вы не хотите выполнять надлежащую проверку токена на серверной части (не вините себя, это боль), затем переключитесь на OIDC. Это лучше подходит для аутентификации и авторизации для интерфейса.

Однако, если ответ SAML отправляется и обрабатывается серверной частью, а в ваше приложение пересылается какой-либо другой токен, вам следует оценить, каковы требования для проверки этого токена.

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