Проблемы с настройкой SAML с помощью Tableau Online

Question

Я пытаюсь настроить соединение SAML для Tableau Online. Я использую pysaml 2 для достижения этой цели. Первая часть конфигурации идет хорошо, Tableau, кажется, считает мой IdP правильным, я ввожу свои учетные данные, но затем происходит сбой входа в систему. Дело в том, что Tableau, очевидно, ждет подписанного ответа, который не отправляет pysaml. Вот ошибка, у меня есть:

Response nor included Assertion is signed], displayableMessage=[null], exceptionClass=[null]

После некоторых исследований я обнаружил, что это связано с:

Identity Provider does not sign SAML assertions.
Verify your IdP configuration.

После копания в коде я могу обнаружить, что pysaml2idp НЕ обнаруживает сертификат, присутствующий в authnrequest. Поэтому он не ставит сертификат в ответ, и поэтому мой ИП не рад этому.

это saml authnrequest:

    <?xml version='1.0' encoding='UTF-8'?>
<ns0:AuthnRequest xmlns:ns0="urn:oasis:names:tc:SAML:2.0:protocol" xmlns:ns1="urn:oasis:names:tc:SAML:2.0:assertion" xmlns:ns2="http://www.w3.org/2000/09/xmldsig#" AssertionConsumerServiceURL="https:/XXXXXXXXXXXXXXXXXXXx" Destination="https://auth.my-numii.io/sso/post" ForceAuthn="false" ID="a114ce90gdg6h2ff1beie36g2jjffj7" IsPassive="false" IssueInstant="2018-06-28T07:30:43.296Z" ProtocolBinding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Version="2.0"><ns1:Issuer>https://sso.online.tableau.com/public/sp/metadata?alias=ea962d84-5953-435d-a6db-71090a3b3e25</ns1:Issuer><ns2:Signature><ns2:SignedInfo><ns2:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#" /><ns2:SignatureMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha256" /><ns2:Reference URI="#a114ce90gdg6h2ff1beie36g2jjffj7"><ns2:Transforms><ns2:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature" /><ns2:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#" /></ns2:Transforms><ns2:DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256" /><ns2:DigestValue>mb4DBX4olvq8tZFtq+zMgSOcBLPjNxi+VbLCyKsaH20=</ns2:DigestValue></ns2:Reference></ns2:SignedInfo><ns2:SignatureValue>T4AK7DNDJ4pMrXB8ndmzXtvyN6RM7sjuAQ9q9l6l4+0P7mdw3JZ3TQKjB9sgwDEwb9Y4ILOrxjELUWLTV7kSXFai8a+E6j241Djmqw+LgzvLXBKFLgamVeizise78cE9WWjZonSOc0MNPYUyTdognFAlREasKkV6Rv6j4wkHu98=</ns2:SignatureValue><ns2:KeyInfo><ns2:X509Data><ns2:X509Certificate>MIICozCCAgygAwIBAgIGAWQ15g7DMA0GCSqGSIb3DQEBCwUAMGwxOzA5BgNVBAsMMmNvbS50YWJs
ZWF1c29mdHdhcmUuc2l0ZXNhbWwuY29yZS51dGlsLkNyeXB0b1V0aWxzMS0wKwYDVQQDDCRlYTk2
MmQ4NC01OTUzLTQzNWQtYTZkYi03MTA5MGEzYjNlMjUwHhcNMTgwNjI0MDc0MzQ2WhcNMjgwNjI1
MDc0MzQ2WjBsMTswOQYDVQQLDDJjb20udGFibGVhdXNvZnR3YXJlLnNpdGVzYW1sLmNvcmUudXRp
bC5DcnlwdG9VdGlsczEtMCsGA1UEAwwkZWE5NjJkODQtNTk1My00MzVkLWE2ZGItNzEwOTBhM2Iz
ZTI1MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDOrUrIzIyKD6hTQBWdxLVtztLXlQIgvEXp
ICdpuSVGZKga+zxcxB9s0qiDN4nYaS9MAYCxnZDO8aiM2Kx5VPygpyv0Vmh/9Ryq61BCEAuVgjNP
OvN158Qw3yGE3pPaGXkPLjCFc6kpdcKakjTB/kHpyZPRRpDnu6xYemO0fEWq/wIDAQABo1AwTjAM
BgNVHRMBAf8EAjAAMB0GA1UdDgQWBBS9YsmNneD8YD3mhYNHs42pQ3MQ9jAfBgNVHSMEGDAWgBS9
YsmNneD8YD3mhYNHs42pQ3MQ9jANBgkqhkiG9w0BAQsFAAOBgQANA3+/sAu7pxI2lmRVDNiiA8wK
YfFuVImZXe1+12priFeOVJuwKCMTfUXPM0rZ+Ktl803uBFPhpnzWCd25vnU/PgMEyISGNw72wzt4
az7z1O7PlLDEPjGCHCE/aHv/HNnJAMKK+hzJ9XPBgk2wLFixa3YOAbZ2FPQ1gurNBfJaiA==</ns2:X509Certificate></ns2:X509Data></ns2:KeyInfo></ns2:Signature></ns0:AuthnRequest>

Я думаю, что мне здесь чего-то не хватает. Есть ли какие-нибудь "хитрости", чтобы подписать мой ответ на Tableau Online?

Answer 1

Несколько сертификатов передаются взад-вперед в зависимости от того, используете ли вы транспорт TLS / SSL, подписываете сообщения, шифруете части сообщения и т. Д. Ключ должен знать, какой сертификат используется кем и для чего.

Сертификат, отправленный в рамках authnrequest (SP-> IdP), используется IdP для проверки подписи в самом запросе, то есть для проверки того, что запрос не был подделан.

Эта часть, кажется, работает (из вашего описания), поскольку ваш IdP запрашивает логин и пытается ответить. (Вы упоминаете, что IdP «не обнаружил» сертификат, и это может быть просто из-за того, что IdP просто решил не проверять подпись запроса.)

Поскольку ваш SP ищет подписанный ответ, IdP использует свой собственный сертификат и отправит / должен отправить сертификат x509 обратно (IdP -> SP), где SP может проверить подписанный ответ. (Подобно запросу SP-> IdP, SP может предпочесть игнорировать проверку подписи в ответе, но похоже, что ваш SP требует подписанных ответов.)

Итак, похоже, это проблема конфигурации IdP: он должен, но не подписывать ответ своим сертификатом (IdP).