SAML: Почему сертификат в Подписи?

Ответ 1

Ответы SAML содержат подпись и открытый ключ для этой подписи.

Вы можете использовать открытый ключ, чтобы убедиться, что содержимое ответа SAML соответствует ключу - другими словами - этот ответ определенно пришел от кого-то, у кого есть соответствующий закрытый ключ к открытому ключу в сообщении, и ответ hasn 't был подделан.

Я не знаю, с какими технологиями вы работаете, но в .Net вы можете проверить это так:

// load a new XML document
var assertion = new XmlDocument { PreserveWhitespace = true };
assertion.LoadXml("The SAML XML that you were sent");

// use a namespace manager to avoid the worst of xpaths
var ns = new XmlNamespaceManager(assertion.NameTable);
ns.AddNamespace("samlp", @"urn:oasis:names:tc:SAML:2.0:protocol");
ns.AddNamespace("asrt", @"urn:oasis:names:tc:SAML:2.0:assertion");
ns.AddNamespace("dsig", @"http://www.w3.org/2000/09/xmldsig#");

// get nodes down to the signature
var responseNode = assertion.SelectSingleNode("/samlp:Response", ns);
var assertionNode = responseNode.SelectSingleNode("asrt:Assertion", ns);
var signNode = assertionNode.SelectSingleNode("dsig:Signature", ns);

// load the XML signature
var signedXml = new SignedXml(assertion.DocumentElement);
signedXml.LoadXml(signNode as XmlElement);

// get the certificate, basically:
//     signedXml.KeyInfo[0].Certificates[0]
// ...but with added casting
var certificate = GetFirstX509Certificate(signedXml);

// check the key and signature match
bool isSigned = signedXml.CheckSignature(certificate, true);

Это просто проверяет, что сообщение от того, кто это говорит. Вам нужна дополнительная проверка того, что сообщение пришло от кого-то, кому вы доверяете, и эта проверка выполняется медленнее - ему нужно включить аннулирование и, возможно, потребуется проверить целую цепочку сертификатов.

Обычно это будет список открытых ключей, на которые вы ответили бы ответы SAML.

Затем вы можете проверить, что это сообщение не было подделано, и принадлежит кому-то, кому вы доверяете, чтобы вы могли разрешить данные пользователя, предоставленные в прилагаемых атрибутах SAML.

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

Например, у вас могут быть два доверенных провайдера - в любом случае вы проверяете, что сообщение не было изменено, прежде чем проверять, доверяете ли вы любому провайдеру. Если ключ не находится в подписи, утверждения могут быть немного меньше, но теперь вы должны заранее знать, из какого поставщика удостоверений было получено утверждение.

Итак, действительно, есть две основные причины, по которым открытый ключ находится в сигнатуре:

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

Ответ 2

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

Например, у вас может быть это в ваших метаданных для утверждающей стороны:

        <KeyDescriptor>
        <ds:KeyInfo>
            <ds:X509Data>
                <ds:X509Certificate>
BQUAMCMxITAfBgNVBAMTGGlkcDEudGFuZ29oZWFsdGhkZW1vLmNvbTAeFw0xMzA1
...snip...
ttHq2Wi5J7img1M2zo28hH5DK78S+XerfXHK2HEZYZs=
                </ds:X509Certificate>
            </ds:X509Data>
            <ds:X509Data>
                <ds:X509Certificate>
H24a88h7zlq+pnAxQm0CAwEAAaN3MHUwVAYDVR0RBE0wS4IYaWRwMS50YW5nb2hl
...snip...
mg1M2zo28hH5DK78=
                </ds:X509Certificate>
            </ds:X509Data>
        </ds:KeyInfo>
    </KeyDescriptor>

Каждый подписанный XML-элемент может указать, какой ключ используется для подписи. Однако в случае SAML 2.0 этот ключ подписи должен (например) соответствовать тому, который определен в метаданных для стороны, создающей подпись. Если ключ, снабженный сигнатурой, не является доверенным (в этом случае не указан в метаданных), тогда система SAML должна генерировать ошибку при проверке подписи.

Ответ 3

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

Тот факт, что он присутствует в спецификациях цифровой подписи XML, на самом деле не имеет особого значения для SAML. Без сертификата, как вы могли бы узнать, откуда появился токен, и как вы можете его проверить?

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

Ответ 4

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

http://developers.onelogin.com/v1.0/page/intro-to-onelogins-open-source-saml-toolkits

http://developers.onelogin.com/v1.0/page/saml-toolkit-for-ruby-on-rails