2014-09-10 3 views
3

Вот часть метаданных SP.SAML 2.0 SP метаданные: Цель и использование сертификата

Ссылка: Metadata for the OASIS Security Assertion Markup Language (SAML) V2.0

... 
<md:KeyDescriptor use="signing"> 
<ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#"> 
    <ds:X509Data> 
     <ds:X509Certificate> 
     </ds:X509Certificate> 
    </ds:X509Data> 
</ds:KeyInfo> 
</md:KeyDescriptor> 
<md:KeyDescriptor use="encryption"> 
<ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#"> 
    <ds:X509Data> 
     <ds:X509Certificate> 
     </ds:X509Certificate> 
    </ds:X509Data> 
</ds:KeyInfo> 
</md:KeyDescriptor> 
... 

Есть ли какие-либо преимущества для выбора такой же (или иной) сертификат как подписи и шифрования сертификата?

В чем заключается цель включения сертификата подписи здесь?

Если сообщение отправлено через https, предоставляется шифрование транспортного уровня. Нужно ли здесь включать сертификат шифрования?

ответ

3

В SAML 2.0 Поставщики метаданных Web SSO обычно объявляют один и тот же сертификат для использования как для подписки, так и для шифрования.

Есть несколько вариантов использования, когда использование разных ключей имеет смысл - например, когда сам SP не должен расшифровывать данные, предоставленные IDP (например, имяID или атрибуты), но это делается только конечным получателем Утверждения; или когда другая сторона предоставляет контент для создания утверждения, чем сторона, которая фактически создает сообщения SAML, но эти случаи использования редки и более важны для других профилей, чем для веб-единого входа.

Сертификат подписи включен для информирования пользователей о метаданных о том, как проверять сообщения, предоставленные эмитентом метаданных. Например, когда SP получает сообщение от IDP, он использует сертификат подписи, определенный в метаданных IDP, чтобы проверить, было ли сообщение создано IDP и не было изменено во время транспортировки.

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

+1

Это не совсем точный. Сертификат подписи используется IdP. Но сертификаты шифрования предоставляются доверяющими сторонами, а IdP использует открытый ключ общедоступного сертификата RP для шифрования данных. При подписании - это предотвращение несанкционированного доступа, шифрование - убедиться, что ни один другой RP не сможет использовать тот же самый токен. И это иногда имеет смысл, например, когда разные токены выдаются различным RP. Существует один сертификат из IdP и возможные дополнительные множественные сертификаты от RP. –

+1

Сертификаты подписи используются как IDP, так и SP, а не только IDP. Кроме того, сертификаты шифрования могут использоваться как IDP, так и SP - SP могут отправлять сообщение SAML (например, AuthnRequest) в IDP и использовать сертификат шифрования, определенный в его метаданных, для его шифрования, а IDP может отправлять зашифрованные сообщения в SP. Шифрование используется для обеспечения конфиденциальности сообщений, его основная цель заключается не в том, чтобы запретить использование токенов другими SP. У SAML есть другие методы предотвращения доставки сообщений SAML непредвиденным получателям, такие как поля «Аудитория» и «Место назначения». –

+1

Правда, правда. Тем не менее, ваши «провайдеры обычно используют одну и ту же пару ключей сертификатов для подписи и шифрования» все еще беспокоят меня. В этом предложении отсутствуют точные «ответы на подпись и шифрование запросов» (поскольку подписание и шифрование ответов с одним и тем же ключом не имеет смысла). –