Support #43613
SLO initié par un SP cassé (?)
0%
Description
Problème qui ne survient que lorsque c'est un des SP qui initie le SLO :
"GET /idp/saml2/slo_return?SAMLResponse=pZLBbsI[…]V%2BpX7Cx%2F81%2FQY%3D&RelayState=_345DF6604A981B1EA9D2818AAE1995CE&SigAlg=http%3A%2F%2Fwww.w3.org%2F2001%2F04%2Fxmldsig-more%23rsa-sha256&Signature=dNcrryV[…]WqQjt0%3D HTTP/1.0" 307 0 2020-06-04 10:19:28 (xml.c/:2577) Processing node 'Issuer' with type 'LassoSaml2NameID' 2020-06-04 10:19:28 (xml.c/:1492) lasso_node_impl_init_from_xml <Issuer> 2020-06-04 10:19:28 (xml.c/:1901) lasso_node_impl_init_from_xml </Issuer> rc=0 2020-06-04 10:19:28 (xml.c/:1451) Matching node Status vs snippet Signature: FAILURE names don't match 2020-06-04 10:19:28 (xml.c/:1451) Matching node Status vs snippet Extensions: FAILURE names don't match 2020-06-04 10:19:28 (xml.c/:1456) Matching node Status vs snippet Status: SUCCESS namespace prefixes match 2020-06-04 10:19:28 (xml.c/:2577) Processing node 'Status' with type '(null)' 2020-06-04 10:19:28 (xml.c/:2577) Processing node 'Status' with type 'LassoSamlp2Status' 2020-06-04 10:19:28 (xml.c/:1492) lasso_node_impl_init_from_xml <Status> 2020-06-04 10:19:28 (xml.c/:1456) Matching node StatusCode vs snippet StatusCode: SUCCESS namespace prefixes match 2020-06-04 10:19:28 (xml.c/:2577) Processing node 'StatusCode' with type '(null)' 2020-06-04 10:19:28 (xml.c/:2577) Processing node 'StatusCode' with type 'LassoSamlp2StatusCode' 2020-06-04 10:19:28 (xml.c/:1492) lasso_node_impl_init_from_xml <StatusCode> 2020-06-04 10:19:28 (xml.c/:1456) Matching node StatusCode vs snippet StatusCode: SUCCESS namespace prefixes match 2020-06-04 10:19:28 (xml.c/:2577) Processing node 'StatusCode' with type '(null)' 2020-06-04 10:19:28 (xml.c/:2577) Processing node 'StatusCode' with type 'LassoSamlp2StatusCode' 2020-06-04 10:19:28 (xml.c/:1492) lasso_node_impl_init_from_xml <StatusCode> 2020-06-04 10:19:28 (xml.c/:1901) lasso_node_impl_init_from_xml </StatusCode> rc=0 2020-06-04 10:19:28 (xml.c/:1901) lasso_node_impl_init_from_xml </StatusCode> rc=0 2020-06-04 10:19:28 (xml.c/:1901) lasso_node_impl_init_from_xml </Status> rc=0 2020-06-04 10:19:28 (xml.c/:1901) lasso_node_impl_init_from_xml </LogoutResponse> rc=0 https://passerelle.dev.publik.love/accounts/mellon/metadata/ denied the logout request
Historique
Mis à jour par Benjamin Dauvergne il y a presque 4 ans
Le SP ne signe pas sa requête de logout, (ça tente de matcher Status avec Signature, ça veut dire qu'il n'a pas trouvé de signature), le SP ne doit pas avoir de clé de signature.
Mis à jour par Paul Marillonnet il y a presque 4 ans
Je n'avais pas remarqué, mais, si l'on reprend par exemple passerelle (bien que l'échec se produise avec tous les SP), les métadonnées exposées dans /accounts/mellon/metadata/
différent avec celle déclarées dans a2 en ce qu'il manque l'attribut xmlns:ds="http://www.w3.org/2000/09/xmldsig#
à la balise ds:KeyInfo
contenant le certificat pour la clé de signature :<EntityDescriptor entityID="https://customname-passerelle.dev.publik.love/accounts/mellon/metadata/">
<SPSSODescriptor AuthnRequestsSigned="true" WantAssertionsSigned="true" protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol">
<KeyDescriptor>
<ds:KeyInfo>
<ds:X509Data>
<ds:X509Certificate>
MIICPDCCAaWgAwIBAgIUNTjnJZJuvHXCtjD9hhnSvRPUEyYwDQYJKoZIhvcNAQELBQAwMDEuMCwGA1UEAwwlY3VzdG9tbmFtZS1wYXNzZXJlbGxlLmRldi5wdWJsaWsubG92ZTAeFw0yMDA2MDMxMzAyNDlaFw0zMDA2MDMxMzAyNDlaMDAxLjAsBgNVBAMMJWN1c3RvbW5hbWUtcGFzc2VyZWxsZS5kZXYucHVibGlrLmxvdmUwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALylbZR8ADYoVWXbvENpL4az/wz2b93ULawNqk2QAb1JJhi1f8EEkh2JqTl/5cktVoEyzCXnMEzGlfB8t/6C58wHZVvi4XQ3AvW0qg/sywPkvIaaywOFKmeLRpz6EJzRdee8lAzkSCv85e+RNt3KwxwIk6yIMfa90Xr4hnyXxVQvAgMBAAGjUzBRMB0GA1UdDgQWBBSwdbl4eVZ3SQFzAS/mh9jmmxxSgDAfBgNVHSMEGDAWgBSwdbl4eVZ3SQFzAS/mh9jmmxxSgDAPBgNVHRMBAf8EBTADAQH/MA0GCSqGSIb3DQEBCwUAA4GBAG35HaR+EpEiV7ZjbFtxZ1qZgfq6pQ7SXC0bQa3UEEibNe2Zr98j+UCTRFCuCDn3c4zY0cTMjK4vvx5OQlB8meTy8uPXbW1DlZmUSTPrvdg3ge5JiH8J290XqcgpGfrfeuuIEiF/XHicxBqg0Im3e1lcyMe72wIXzhMoUIUY0Bc1
</ds:X509Certificate>
</ds:X509Data>
</ds:KeyInfo>
</KeyDescriptor>
<SingleLogoutService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect" Location="https://customname-passerelle.dev.publik.love/accounts/mellon/logout/"/>
<AssertionConsumerService index="0" isDefault="true" Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Artifact" Location="https://customname-passerelle.dev.publik.love/accounts/mellon/login/"/>
<AssertionConsumerService index="1" Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location="https://customname-passerelle.dev.publik.love/accounts/mellon/login/"/>
</SPSSODescriptor>
</EntityDescriptor>
Mis à jour par Paul Marillonnet il y a presque 4 ans
(Et non, c'est l'attribut qui est masqué par le visualisateur XML de Firefox…)
Mis à jour par Paul Marillonnet il y a presque 4 ans
- Statut changé de Nouveau à Fermé
Bon, ayant suivi le conseil d'Emmanuel i.e. redéploiement du tenant, je ne reproduis plus le bogue, étrange. Je ferme le ticket.
Mis à jour par Benjamin Dauvergne il y a presque 4 ans
Paul Marillonnet a écrit :
Bon, ayant suivi le conseil d'Emmanuel i.e. redéploiement du tenant, je ne reproduis plus le bogue, étrange. Je ferme le ticket.
Tu as du avoir un foirage lors de son déploiement initialement, comme ce n'est pas transactionnel et que ça se fait en fin de déploiement de calculer les clés, ça a pu passer inaperçu assez longtemps sur un passerelle (sur un combo tu aurais perdu le thème en plus, c'est plus visible :
def deploy_specifics(self, hobo_environment, tenant): # configure things that are quite common but may actually not be # common to *all* tenants. self.generate_saml_keys(tenant, prefix='sp-') self.configure_service_provider(hobo_environment, tenant) self.configure_theme(hobo_environment, tenant) self.configure_template(hobo_environment, tenant)
note que tu n'aurais pas du avoir de SSO non plus, c'est configure_service_provider()
, ça reste étrange)
Mis à jour par Paul Marillonnet il y a presque 4 ans
Benjamin Dauvergne a écrit :
Tu as du avoir un foirage lors de son déploiement initialement, comme ce n'est pas transactionnel et que ça se fait en fin de déploiement de calculer les clés, ça a pu passer inaperçu assez longtemps sur un passerelle (sur un combo tu aurais perdu le thème en plus, c'est plus visible :
[...]
note que tu n'aurais pas du avoir de SSO non plus, c'est
configure_service_provider()
, ça reste étrange)
Je n'avais pas compris au moment de la création de ce ticket que ce souci de SLO est un comportement qui survient lors de ma procédure de test en local pour la revue de code de #41949 – comportement dont la reproductibilité est documentée dans #41949-21.