Метаданные SAML 2.0 SP: цель и использование сертификата

Вот часть метаданных SP.

Ссылка: метаданные для разметки подтверждения безопасности OASIS Язык (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, предоставляется шифрование на транспортном уровне. Нам все еще нужно включать сертификат шифрования здесь?


metadata saml-2.0 service-provider
person tony.0919    schedule 10.09.2014    source источник

Ответы (1)


arrow_upward
8
arrow_downward

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

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

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

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

person Vladimír Schäfer    schedule 10.09.2014
comment
Это не совсем точно. Сертификат подписи используется IdP. Но сертификаты шифрования предоставляются проверяющими сторонами, и IdP использует открытый ключ открытого сертификата RP для шифрования данных. В то время как подпись предназначена для предотвращения несанкционированного доступа, шифрование должно гарантировать, что никакая другая RP не сможет использовать тот же токен. И это иногда имеет смысл, например, когда разные токены выдаются разным RP. Затем имеется один сертификат от IdP и, возможно, несколько необязательных сертификатов от RP. - person Wiktor Zychla; 10.09.2014
comment
Сертификаты подписи используются как IDP, так и SP, а не только IDP. Кроме того, сертификаты шифрования могут использоваться как IDP, так и SP — SP может отправлять сообщение SAML (например, AuthnRequest) IDP и использовать сертификат шифрования, определенный в его метаданных, для его шифрования, а также IDP может отправлять зашифрованные сообщения SP. Шифрование используется для обеспечения конфиденциальности сообщений, его основной целью является не предотвращение использования токенов другими поставщиками услуг. В SAML есть и другие методы предотвращения доставки сообщений SAML непреднамеренным получателям, например поля Audience и Destination. - person Vladimír Schäfer; 10.09.2014
comment
Правда правда. Однако ваши провайдеры обычно используют одну и ту же пару сертификат-ключ для подписи, и шифрование меня все еще беспокоит. В этом предложении отсутствует точная подпись ответов и шифрование запросов (поскольку подписание и шифрование ответов одним и тем же ключом не имеет смысла). - person Wiktor Zychla; 11.09.2014
comment
Вопрос и ответ обсуждаются в контексте метаданных SAML, поэтому используйте те же ключевые средства, что и в документе метаданных SAML. Тот факт, что вы не шифруете сообщения с помощью собственного ключа, должен быть очевиден из базовых знаний криптографии с открытым ключом, так как в этом случае шифровальщик будет единственным лицом, способным расшифровать сообщение. Но я изменю формулировку, чтобы никого не смущать, спасибо за комментарий. - person Vladimír Schäfer; 11.09.2014
comment
На самом деле было доказано, что вы можете подменять подписи XML и вставлять дополнительный контент. во время передачи пакета. Я традиционно принудительно использую шифрование утверждения и, возможно, подпись ответа, если считаю, что это стоит ордера. - person Aeos Mayor; 10.11.2015