2015-09-30 9 views
0

Я изучаю эту тему на некоторое время без большой удачи.Как аутентифицировать доверяющую сторону SAML с использованием веб-приложения в качестве клиента

Сценарий: 1. Войдите в веб-приложение с использованием стандартной проверки подлинности. 2. Войдите в систему из веб-приложения в сторону SAML.

Вопрос: Я подумал об использовании iFrame для аутентификации в SAML Relying Party. Основная проблема в этом подходе заключается в том, что после завершения потока аутентификации SAML мне нужно перенести постоянный токен аутентификации на мой клиент веб-приложения (этот токен используется для последующего доступа моего веб-приложения к полагающейся стороне SAML).

. Может ли кто-нибудь прокомментировать, является ли это правильным подходом (безопасность разумна)?

. Существует ли альтернативный подход для аутентификации веб-клиентов в системе, настроенной как полагающаяся сторона SAML?

Спасибо заранее,

Saimon

+0

Если я понимаю ваш вопрос, вы описываете инициированный IDP SSO: http://saml.xml.org/wiki/idp-initiated-single-sign-on-post-binding.Я предполагаю это, потому что вы пишете: «Войдите в веб-приложение с использованием стандартной проверки подлинности» - так звучит, что приложение действует как IDP. Однако ваша проблема смущает меня: вы можете проверить определение «полагающейся стороны». – judielaine

ответ

0

Вопрос, который вы задаете фундаментальный вопрос федерации. Что касается SAML, то есть Identity Provider (IdP) и поставщик услуг. IdP несет ответственность за аутентификацию пользователя и выдачу утверждений SAML для веб-приложений SP. В вашем вопросе звучит так, что ваше приложение - это IdP, который хочет опубликовать утверждение SAML в веб-приложении SP (я интерпретировал вашу доверяющую сторону SAML для обозначения веб-приложения SP). Имейте в виду, что утверждения SAML ориентированы на одноразовое использование для аутентификации в веб-приложении SP, где утверждение SAML может содержать атрибуты, используемые для AuthZ.

Другой архитектурой будет интеграция стороннего SAML IdP, так что ваше приложение является SP, а другое приложение является SP. Оба веб-приложения SP будут использовать IdP для AuthN и получать утверждения SAML. Опять же, речь идет об AuthN и однократном использовании информации в утверждении SAML.

Другой архитектурой будет использование OpenID Connect (OIDC) с сервера IdP. Основное различие заключается в том, что токены могут быть долговечными и использоваться для последующих безопасных транзакций API.

В отношении безопасности все эти протоколы имеют встроенную в них защиту при правильной интеграции их соответствующей архитектуры.

0

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

Вы можете сделать аутентификацию автоматически в фоновом режиме, но тогда вам нужно иметь дело с CORS с обеих сторон (поставщик удостоверений и поставщик услуг). Ваш подход проще, так как это действие пользователя, поэтому CORS не требуется. К вашей проблеме: похоже, что ваш токен является частью заголовка как специальный заголовок с определенным именем. Лучший подход в вашем случае (если это возможно): Сохраните этот токен в Cookie. В вашем подходе файл cookie должен быть разделен между различными кадрами. Затем ваше приложение может отправлять cookie при доступе к ресурсу. Но имейте в виду: с помощью Javascript & XMLHTTPREQUEST вам нужно установить «withCredentials».