2013-03-09 4 views
0

Я создал некоторую модель аутентификации в Sharepoint. Хотелось бы узнать у вас, что это хороший подход.Создать токен для аутентификации в приложении RP

У нас есть IDP, который отправляет токен POST SAML в версии 2.0, но приложение RP не поддерживает SAML в этой версии, но в версии 1.1.

Я создал для этого такой модели:

  1. IDP посылает SAML 2.0 на SAMLHandler.aspx странице

  2. SAMLHandler.aspx проверяет маркер в SAML 2.0 (подпись) и получить коллекцию претензий от it

  3. Основываясь на множестве претензий, я создаю токен SAML в v1.1, поддерживаемый Sharepoint, и этот токен подписывается некоторым сертификатом с паролем (этот сертификат добавляется в хранилище Trustpoint Manage Trust).

  4. Этот токен SAML v1.1 упакован в сообщение WIF и отправляет в Sharepoint, который распознает претензии, и, наконец, пользователь аутентифицирован В порядке?

ответ

0

Вы можете использовать решение, как ACS (Azure службы управления) вместо SAMLHandler.aspx, в результате вы будете иметь возможность обрабатывать более одного МВУ и когда-либо создать единый вход в систему.

В основном ваше решение выглядит хорошо, но повторно инвертирует существующие вещи.

+0

Хорошо, но я должен использовать страницу авторизации IDP, но ранее, когда я хочу получить доступ к этой странице авторизации, я должен отправить POST SAMLRequest с подписью, а затем IDP подтвердит и предоставит мне доступ к этой странице. После этого этот IDP дает мне SAMLResponse, который я буду обрабатывать SAMLHandler.aspx, поэтому ACS, я думаю, в этом случае не в порядке? – user2151581

+0

Таким образом, прокси-сервер IDP является этим обработчиком, и я использую STS для доступа к пользовательскому авторизации, поэтому мой ISSUER теперь не является оригинальным IDP, который отправил SAMLResponse, но Sharepoint, где я создаю SAML 1.1 правильно? – user2151581

+0

Кто-нибудь знает, хорошо ли он подходит, и его можно решить, как я описал выше? Thanx для любой дополнительной информации. – user2151581

0

Вы можете посмотреть службу маркеров безопасности. Его можно использовать для обмена одним токеном безопасности с другим токеном безопасности. В вашем случае вам необходимо обменять токен SAML 2.0 с помощью токена SAML 1.1. Служба Token Service также поддерживает проверку токена и подписывание токенов.

+0

Хорошо, но STS в Sharepoint в этом случае должен подписать этот токен, а не внешний IDP, потому что SAMLHandler.aspx добавляется в IIS, где экземпляр Sharepoint существует. Наконец, этот обработчик переводит с SAML 2.0 на SAML 1.1 и подписывает этот токен на любой сертификат? Поэтому мой вопрос заключается в том, должен ли я использовать какой-либо правый сертификат в SAML 1.1, или это не имеет значения, так что этот SAMLHandler работает здесь, как прокси-сервер IDP или что-то подобное. Thanx для любой информации – user2151581

Смежные вопросы