Projet

Général

Profil

Support #43613

SLO initié par un SP cassé (?)

Ajouté par Paul Marillonnet il y a presque 4 ans. Mis à jour il y a presque 4 ans.

Statut:
Fermé
Priorité:
Normal
Assigné à:
-
Version cible:
-
Début:
04 juin 2020
Echéance:
% réalisé:

0%

Temps estimé:
Patch proposed:
Non
Planning:
Non

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

#1

Mis à jour par Paul Marillonnet il y a presque 4 ans

  • Description mis à jour (diff)
#2

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.

#3

Mis à jour par Benjamin Dauvergne il y a presque 4 ans

Il est configuré comment ce SP ?

#4

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>

#5

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…)

#6

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.

#7

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)

#8

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.

Formats disponibles : Atom PDF