I have just published a new version which avoids this problem.
@djay I was trying to configure dm.zope.saml2 in Plone 4.3 to use Microsoft with IdP. Then I was getting the error:
MetadataFetchError: MetadataFetchError for https://sts.windows.net/b5661350-c2e4-43dc-bce8-f003ddf8a3c4/: http://docs.oasis-open.org/wsfed/federation/200706 has no category typeBinding
I then added collective.saml2 to the buildout via mr.developer and the error stopped occurring.
Someone put collective.saml2 in pypi:
But this version is broken see:
It seems that the user who put it in pypi has no intention of adding new maintainers. So I ask if it would be possible to change the name of the product so I can put it in pypi. Is there a mirror with a correct version?
I alerted @dieter and the plone security team of this, back in november 2022. Wondering why there was no follow up from either.
Norbert via Plone Community wrote at 2024-6-10 22:17 +0000:
I alerted @dieter and the plone security team of this, back in november 2022. Wondering why there was no follow up from either.
I am only responsible for dm.zope.saml2 (not collective.saml2).
I am aware that someone who wants to integrate dm.zope.saml2 with
SAML authorities with extended metadata or
SAML messages (such as a MicroSoft identify provider)
may need to register additional XML-schemata with PyXB
(such that the metadata/messages are understood).
This is not a security issue, however.
The dm.saml2 documentation hints towards this problem
in section Dependencies --> PyXB with respect to
the "SAML2 context classes" (which are not known to
typical PyXB installations).
At the moment, I do not recommend the use of
dm.zope.saml2 to make Plone an SAML service provider
(difficult dependencies, quite difficult installation).
Instead, I would go for a standard SAML2 service provider
module for the WebServer and delegate SAML based authentication
to this module, communication via SAML related headers between
WebServer and Plone.
One will find corresponding details by searching the archives of this list.
@dieter @djay I configured dm.zope.saml2 + collective.saml2 to use ADFS as IdP. I get the response from the IdP but I get the error:
2024-06-17T15:43:33 ERROR Zope.SiteErrorLog 1718649813.950.985810416323 https://site.com/clientes/site/Plone/acl_users/saml2sp/post
Traceback (innermost last):
Module ZPublisher.Publish, line 138, in publish
Module ZPublisher.mapply, line 77, in mapply
Module ZPublisher.Publish, line 48, in call_object
Module dm.zope.saml2.browser.role, line 47, in post
Module dm.zope.saml2.browser.role, line 69, in _process
- __traceback_info__: <samlp:Response ID="_de2e9874-7814-4a9c-b53f-23ee1ca078f4" Version="2.0" IssueInstant="2024-06-17T18:43:33.772Z" Destination="https://site.com/clientes/site/Plone/acl_users/saml2sp/post" InResponseTo="_e540a97b-acd3-44bb-9a53-a4ce89f3453f" xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"><Issuer xmlns="urn:oasis:names:tc:SAML:2.0:assertion">https://sts.windows.net/b5661350-c2e4-43dc-bce8-f003ddf8a3c4/</Issuer><samlp:Status><samlp:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Success"/></samlp:Status><Assertion ID="_724d62ff-a2f3-49e5-ab68-dab4c6e73f00" IssueInstant="2024-06-17T18:43:33.769Z" Version="2.0" xmlns="urn:oasis:names:tc:SAML:2.0:assertion"><Issuer>https://sts.windows.net/b5661350-c2e4-43dc-bce8-f003ddf8a3c4/</Issuer><Signature xmlns="http://www.w3.org/2000/09/xmldsig#"><SignedInfo><CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/><SignatureMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha256"/><Reference URI="#_724d62ff-a2f3-49e5-ab68-dab4c6e73f00"><Transforms><Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/><Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/></Transforms><DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"/><DigestValue>vbVITgEMva3gUtXFgLvitsNp6jUV00iF2JKdHzyeI1E=</DigestValue></Reference></SignedInfo><SignatureValue>123</SignatureValue><KeyInfo><X509Data><X509Certificate>123</X509Certificate></X509Data></KeyInfo></Signature><Subject><NameID Format="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress">user@email.com</NameID><SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer"><SubjectConfirmationData InResponseTo="_e540a97b-acd3-44bb-9a53-a4ce89f3453f" NotOnOrAfter="2024-06-17T19:43:33.518Z" Recipient="https://site.com/clientes/site/Plone/acl_users/saml2sp/post"/></SubjectConfirmation></Subject><Conditions NotBefore="2024-06-17T18:38:33.518Z" NotOnOrAfter="2024-06-17T19:43:33.518Z"><AudienceRestriction><Audience>https://site.com/</Audience></AudienceRestriction></Conditions><AttributeStatement><Attribute Name="http://schemas.microsoft.com/identity/claims/tenantid"><AttributeValue>b5661350-c2e4-43dc-bce8-f003ddf8a3c4</AttributeValue></Attribute><Attribute Name="http://schemas.microsoft.com/identity/claims/objectidentifier"><AttributeValue>10b9089c-e0fa-413f-b1a9-b1417fa17503</AttributeValue></Attribute><Attribute Name="http://schemas.microsoft.com/identity/claims/displayname"><AttributeValue>User</AttributeValue></Attribute><Attribute Name="http://schemas.microsoft.com/identity/claims/identityprovider"><AttributeValue>https://sts.windows.net/c2db1c4d-29e6-4330-85e3-fb54b7696668/</AttributeValue></Attribute><Attribute Name="http://schemas.microsoft.com/claims/authnmethodsreferences"><AttributeValue>http://schemas.microsoft.com/claims/multipleauthn</AttributeValue><AttributeValue>http://schemas.microsoft.com/ws/2008/06/identity/authenticationmethod/unspecified</AttributeValue></Attribute><Attribute Name="http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress"><AttributeValue>user@email.com</AttributeValue></Attribute><Attribute Name="http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name"><AttributeValue>user@email.com</AttributeValue></Attribute></AttributeStatement><AuthnStatement AuthnInstant="2024-06-17T13:14:25.489Z" SessionIndex="_724d62ff-a2f3-49e5-ab68-dab4c6e73f00"><AuthnContext><AuthnContextClassRef>urn:oasis:names:tc:SAML:2.0:ac:classes:unspecified</AuthnContextClassRef></AuthnContext></AuthnStatement></Assertion></samlp:Response>
Module dm.saml2.signature, line 389, in CreateFromDocument
Module dm.saml2.signature, line 368, in verify_signatures
Module dm.saml2.signature, line 363, in verify
Module dm.saml2.signature, line 356, in verify
Module dm.zope.saml2.authority, line 409, in verify
Module dm.saml2.signature, line 241, in verify
VerifyError: signature verification failed: _724d62ff-a2f3-49e5-ab68-dab4c6e73f00 https://sts.windows.net/123/
Do you know what it could be?
Wesley Barroso Lopes via Plone Community wrote at 2024-6-17 20:30 +0000:
@dieter @djay I configured dm.zope.saml2 + collective.saml2 to use ADFS as IdP. I get the response from the IdP but I get the error:
2024-06-17T15:43:33 ERROR Zope.SiteErrorLog 1718649813.950.985810416323 https://site.com/clientes/site/Plone/acl_users/saml2sp/post ... Module dm.saml2.signature, line 241, in verify VerifyError: signature verification failed: _724d62ff-a2f3-49e5-ab68-dab4c6e73f00 https://sts.windows.net/b5661350-c2e4-43dc-bce8-f003ddf8a3c4/Do you know what it could be?
The error message tells you that the verification has failed.
Usually, I would say: read the dm.xmlsec.binding documentation
and learn there how to get error details.
Unfortunately, I recently recognized that the last published
version is no longer compatible with modern Python and/or cython
versions: using the error callback can lead to a SIGSEGV
(because xmlsec sometime returns NULL as part of the error details
which is no longer automatically transformed into None but leads
to a crash).
Thus, obtaining error details might not work (but you could try).
I am working on a fix -- but it may still take some time.
If it does not work, we can try a guess:
have you properly initialized dm.xmlsec.binding as
you have been told to do by the installation instructions?
If not, failure is to be expected.
I'm using Python 2.7
How do I do this?
collective.saml2 initialize dm.xmlsec.binding:
I did not configure a certificate in the dm.zope.saml2 configuration. Do I need to do this when my portal is an SP?
Wesley Barroso Lopes via Plone Community wrote at 2024-6-17 21:30 +0000:
...
How do I do this?
You start by reading the installation instructions of dm.zope.saml2 and
the error_callback details in the documentation of
dm.xmlsec.binding.
I did not configure a certificate in the
dm.zope.saml2configuration. Do I need to do this when my portal is an SP?
You need the private key and certificate only when your
SAML entity must sign something.
It is possible that an SP must sign something but apparently
not in your case (otherwise, you would not have reached the point
of the reported error).
Your error happens during the processing (actually the verification)
of the incoming SAML message from the IDP.
Beside the message, it uses the certificate information from
the IDP metadata.
When my portal was registered with the IdP, they sent me a certificate. I did not register this certificate on my portal server. Could it be that the OS didn't trust the IdP's response certificate, and the certificate they sent me when registering is a CA that I need to register on my server, to be able to validate the response certificate? That makes sense?
In fact, the certificate sent when registering the SP is not a CA. It's a normal certificate. Where do I configure it on my server?
Wesley Barroso Lopes via Plone Community wrote at 2024-6-18 15:06 +0000:
...
When my portal was registered with the IdP, they sent me a certificate. I did not register this certificate on my portal server. Could it be that the OS didn't trust the IdP's response certificate, and the certificate they sent me when registering is a CA that I need to register on my server, to be able to validate the response certificate? That makes sense?
In principle, dm.zope.saml2 is strongly metadata oriented:
each SAML entity must be decribed by a metadata document.
If an SAML entity signs its documents, then its metadata must
contain information which allows the verification of the signature.
This typically is a certificate.
The verification itself is not done by dm.zope.saml2 but
delegated to the XML Security Library ("libxmlsec1") which
in turn delegates it to one of its crypto modules
(under *nix usually OpenSSL). This means are the verification
details are deeply hidden.
In all cases, I have seen so far, the verification has
trusted a certificate published as part of the metadata,
even if the certificate has been self signed (e.g. was
not issued by a trusted "Certificate Authority" or was no
longer valid). However, XML-Signature is an incredibly complex
standard and I definitely have seen only a tiny part of the
possible scenarios. It is well possible that the signature
information in a signed document can request strict certificate
verification.
There are really a large number of problems which may cause
a verification failure.
I suggest you try to activate the dm.xmlsec.binding error callback
to get hints for the verification problems.
As noted earlier, it is possible that the use of
the callback may crash the process.
If you have downloaded the dm.xmlsec.binding source distribution,
you can call python setup.py test in its top level
directory to run its test suite.
If this does not crash then the error callback should work
in your Plone as well.
If it does crash, I see the following options:
-
you wait until I release a new version of
dm.xmlsec.binding
fixing the "error callback" problemBecause I work on the much bigger task to bring
dm.xmlsec.bindingin line with the current
xmlsecrelease (1.3.x) and have serious problems with it,
this may take a considerable time. -
you use the
xmlsec1command line utility (part
of "libxmlsec1") to perform the verification.You can look at
dm.saml2.signature.SignatureContext.verify
to learn how the verification is performed
and atdm.zope.saml2.authority.SamlAuthority._add_verify_keys
to learn howdm.zope.saml2determines the certificates
from the metadata document.
If you go this route you must extract the certificates
to files and emulate the verification process
via anxmlsec1call with properly chosen options.I expect that
xmlsec1either shows error details automatically
or has an option to let it do so.
Wesley Barroso Lopes via Plone Community wrote at 2024-6-18 15:46 +0000:
In fact, the certificate sent when registering the SP is not a CA. It's a normal certificate. Where do I configure it on my server?
I assume that "the certificate sent when registering the SP"
still is associated with the IDP (and not the SP) despite the strange
phrase. Correct?
In this case, the certificate should be part of the
metadata document describing the IDP (read my previous answer).
You do not register the certificate in isolation but you
have specified an URL when creating the SAML entity
representing the IDP and this URL tells dm.zope.saml2
from where to fetch the IDPs metadata.
@dieter I think I figured out what the problem is. The SAML2 response certificate is not in the metadata xml registered in the SP. Is this an error? Have you ever seen a situation like this? The IdP is Microsoft 365.
Has anyone seen this? How to configure Microsoft 365 to return certificate in metadata xml?
The xml URL is something like:
https://login.microsoftonline.com/123/federationmetadata/2007-06/federationmetadata.xml
In fact, XML comes with several certificates, but none are the ones from the SAML response. Could it be that the certificate is out of date in some configuration? Below is the metadata XML modified to hide data:
<?xml version="1.0" encoding="UTF-8"?>
<EntityDescriptor xmlns="urn:oasis:names:tc:SAML:2.0:metadata" ID="_e6a401fc-fcc4-4f52-8a15-e6cedfcc432b" entityID="https://sts.windows.net/123/">
<Signature xmlns="http://www.w3.org/2000/09/xmldsig#">
<SignedInfo>
<CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#" />
<SignatureMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha256" />
<Reference URI="#_e6a401fc-fcc4-4f52-8a15-e6cedfcc432b">
<Transforms>
<Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature" />
<Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#" />
</Transforms>
<DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256" />
<DigestValue>3C3pnCxbPn/Mk75rtqnU645UTfgz+EC0O1yhFmeEsMA=</DigestValue>
</Reference>
</SignedInfo>
<SignatureValue>123</SignatureValue>
<KeyInfo>
<ds:X509Data xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
<ds:X509Certificate>123</ds:X509Certificate>
</ds:X509Data>
</KeyInfo>
</Signature>
<RoleDescriptor xmlns:fed="http://docs.oasis-open.org/wsfed/federation/200706" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="fed:SecurityTokenServiceType" protocolSupportEnumeration="http://docs.oasis-open.org/wsfed/federation/200706">
<KeyDescriptor use="signing">
<KeyInfo xmlns="http://www.w3.org/2000/09/xmldsig#">
<X509Data>
<X509Certificate>123</X509Certificate>
</X509Data>
</KeyInfo>
</KeyDescriptor>
<KeyDescriptor use="signing">
<KeyInfo xmlns="http://www.w3.org/2000/09/xmldsig#">
<X509Data>
<X509Certificate>123</X509Certificate>
</X509Data>
</KeyInfo>
</KeyDescriptor>
<KeyDescriptor use="signing">
<KeyInfo xmlns="http://www.w3.org/2000/09/xmldsig#">
<X509Data>
<X509Certificate>123</X509Certificate>
</X509Data>
</KeyInfo>
</KeyDescriptor>
<KeyDescriptor use="signing">
<KeyInfo xmlns="http://www.w3.org/2000/09/xmldsig#">
<X509Data>
<X509Certificate>123</X509Certificate>
</X509Data>
</KeyInfo>
</KeyDescriptor>
<KeyDescriptor use="signing">
<KeyInfo xmlns="http://www.w3.org/2000/09/xmldsig#">
<X509Data>
<X509Certificate>123</X509Certificate>
</X509Data>
</KeyInfo>
</KeyDescriptor>
<KeyDescriptor use="signing">
<KeyInfo xmlns="http://www.w3.org/2000/09/xmldsig#">
<X509Data>
<X509Certificate>123</X509Certificate>
</X509Data>
</KeyInfo>
</KeyDescriptor>
<KeyDescriptor use="signing">
<KeyInfo xmlns="http://www.w3.org/2000/09/xmldsig#">
<X509Data>
<X509Certificate>123</X509Certificate>
</X509Data>
</KeyInfo>
</KeyDescriptor>
<fed:ClaimTypesOffered>
<auth:ClaimType xmlns:auth="http://docs.oasis-open.org/wsfed/authorization/200706" Uri="http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name">
<auth:DisplayName>Name</auth:DisplayName>
<auth:Description>The mutable display name of the user.</auth:Description>
</auth:ClaimType>
<auth:ClaimType xmlns:auth="http://docs.oasis-open.org/wsfed/authorization/200706" Uri="http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier">
<auth:DisplayName>Subject</auth:DisplayName>
<auth:Description>An immutable, globally unique, non-reusable identifier of the user that is unique to the application for which a token is issued.</auth:Description>
</auth:ClaimType>
<auth:ClaimType xmlns:auth="http://docs.oasis-open.org/wsfed/authorization/200706" Uri="http://schemas.xmlsoap.org/ws/2005/05/identity/claims/givenname">
<auth:DisplayName>Given Name</auth:DisplayName>
<auth:Description>First name of the user.</auth:Description>
</auth:ClaimType>
<auth:ClaimType xmlns:auth="http://docs.oasis-open.org/wsfed/authorization/200706" Uri="http://schemas.xmlsoap.org/ws/2005/05/identity/claims/surname">
<auth:DisplayName>Surname</auth:DisplayName>
<auth:Description>Last name of the user.</auth:Description>
</auth:ClaimType>
<auth:ClaimType xmlns:auth="http://docs.oasis-open.org/wsfed/authorization/200706" Uri="http://schemas.microsoft.com/identity/claims/displayname">
<auth:DisplayName>Display Name</auth:DisplayName>
<auth:Description>Display name of the user.</auth:Description>
</auth:ClaimType>
<auth:ClaimType xmlns:auth="http://docs.oasis-open.org/wsfed/authorization/200706" Uri="http://schemas.microsoft.com/identity/claims/nickname">
<auth:DisplayName>Nick Name</auth:DisplayName>
<auth:Description>Nick name of the user.</auth:Description>
</auth:ClaimType>
<auth:ClaimType xmlns:auth="http://docs.oasis-open.org/wsfed/authorization/200706" Uri="http://schemas.microsoft.com/ws/2008/06/identity/claims/authenticationinstant">
<auth:DisplayName>Authentication Instant</auth:DisplayName>
<auth:Description>The time (UTC) when the user is authenticated to Windows Azure Active Directory.</auth:Description>
</auth:ClaimType>
<auth:ClaimType xmlns:auth="http://docs.oasis-open.org/wsfed/authorization/200706" Uri="http://schemas.microsoft.com/ws/2008/06/identity/claims/authenticationmethod">
<auth:DisplayName>Authentication Method</auth:DisplayName>
<auth:Description>The method that Windows Azure Active Directory uses to authenticate users.</auth:Description>
</auth:ClaimType>
<auth:ClaimType xmlns:auth="http://docs.oasis-open.org/wsfed/authorization/200706" Uri="http://schemas.microsoft.com/identity/claims/objectidentifier">
<auth:DisplayName>ObjectIdentifier</auth:DisplayName>
<auth:Description>Primary identifier for the user in the directory. Immutable, globally unique, non-reusable.</auth:Description>
</auth:ClaimType>
<auth:ClaimType xmlns:auth="http://docs.oasis-open.org/wsfed/authorization/200706" Uri="http://schemas.microsoft.com/identity/claims/tenantid">
<auth:DisplayName>TenantId</auth:DisplayName>
<auth:Description>Identifier for the user's tenant.</auth:Description>
</auth:ClaimType>
<auth:ClaimType xmlns:auth="http://docs.oasis-open.org/wsfed/authorization/200706" Uri="http://schemas.microsoft.com/identity/claims/identityprovider">
<auth:DisplayName>IdentityProvider</auth:DisplayName>
<auth:Description>Identity provider for the user.</auth:Description>
</auth:ClaimType>
<auth:ClaimType xmlns:auth="http://docs.oasis-open.org/wsfed/authorization/200706" Uri="http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress">
<auth:DisplayName>Email</auth:DisplayName>
<auth:Description>Email address of the user.</auth:Description>
</auth:ClaimType>
<auth:ClaimType xmlns:auth="http://docs.oasis-open.org/wsfed/authorization/200706" Uri="http://schemas.microsoft.com/ws/2008/06/identity/claims/groups">
<auth:DisplayName>Groups</auth:DisplayName>
<auth:Description>Groups of the user.</auth:Description>
</auth:ClaimType>
<auth:ClaimType xmlns:auth="http://docs.oasis-open.org/wsfed/authorization/200706" Uri="http://schemas.microsoft.com/identity/claims/accesstoken">
<auth:DisplayName>External Access Token</auth:DisplayName>
<auth:Description>Access token issued by external identity provider.</auth:Description>
</auth:ClaimType>
<auth:ClaimType xmlns:auth="http://docs.oasis-open.org/wsfed/authorization/200706" Uri="http://schemas.microsoft.com/ws/2008/06/identity/claims/expiration">
<auth:DisplayName>External Access Token Expiration</auth:DisplayName>
<auth:Description>UTC expiration time of access token issued by external identity provider.</auth:Description>
</auth:ClaimType>
<auth:ClaimType xmlns:auth="http://docs.oasis-open.org/wsfed/authorization/200706" Uri="http://schemas.microsoft.com/identity/claims/openid2_id">
<auth:DisplayName>External OpenID 2.0 Identifier</auth:DisplayName>
<auth:Description>OpenID 2.0 identifier issued by external identity provider.</auth:Description>
</auth:ClaimType>
<auth:ClaimType xmlns:auth="http://docs.oasis-open.org/wsfed/authorization/200706" Uri="http://schemas.microsoft.com/claims/groups.link">
<auth:DisplayName>GroupsOverageClaim</auth:DisplayName>
<auth:Description>Issued when number of user's group claims exceeds return limit.</auth:Description>
</auth:ClaimType>
<auth:ClaimType xmlns:auth="http://docs.oasis-open.org/wsfed/authorization/200706" Uri="http://schemas.microsoft.com/ws/2008/06/identity/claims/role">
<auth:DisplayName>Role Claim</auth:DisplayName>
<auth:Description>Roles that the user or Service Principal is attached to</auth:Description>
</auth:ClaimType>
<auth:ClaimType xmlns:auth="http://docs.oasis-open.org/wsfed/authorization/200706" Uri="http://schemas.microsoft.com/ws/2008/06/identity/claims/wids">
<auth:DisplayName>RoleTemplate Id Claim</auth:DisplayName>
<auth:Description>Role template id of the Built-in Directory Roles that the user is a member of</auth:Description>
</auth:ClaimType>
</fed:ClaimTypesOffered>
<fed:SecurityTokenServiceEndpoint>
<wsa:EndpointReference xmlns:wsa="http://www.w3.org/2005/08/addressing">
<wsa:Address>https://login.microsoftonline.com/123/wsfed</wsa:Address>
</wsa:EndpointReference>
</fed:SecurityTokenServiceEndpoint>
<fed:PassiveRequestorEndpoint>
<wsa:EndpointReference xmlns:wsa="http://www.w3.org/2005/08/addressing">
<wsa:Address>https://login.microsoftonline.com/123/wsfed</wsa:Address>
</wsa:EndpointReference>
</fed:PassiveRequestorEndpoint>
</RoleDescriptor>
<RoleDescriptor xmlns:fed="http://docs.oasis-open.org/wsfed/federation/200706" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="fed:ApplicationServiceType" protocolSupportEnumeration="http://docs.oasis-open.org/wsfed/federation/200706">
<KeyDescriptor use="signing">
<KeyInfo xmlns="http://www.w3.org/2000/09/xmldsig#">
<X509Data>
<X509Certificate>123</X509Certificate>
</X509Data>
</KeyInfo>
</KeyDescriptor>
<KeyDescriptor use="signing">
<KeyInfo xmlns="http://www.w3.org/2000/09/xmldsig#">
<X509Data>
<X509Certificate>123</X509Certificate>
</X509Data>
</KeyInfo>
</KeyDescriptor>
<KeyDescriptor use="signing">
<KeyInfo xmlns="http://www.w3.org/2000/09/xmldsig#">
<X509Data>
<X509Certificate>123</X509Certificate>
</X509Data>
</KeyInfo>
</KeyDescriptor>
<KeyDescriptor use="signing">
<KeyInfo xmlns="http://www.w3.org/2000/09/xmldsig#">
<X509Data>
<X509Certificate>123</X509Certificate>
</X509Data>
</KeyInfo>
</KeyDescriptor>
<KeyDescriptor use="signing">
<KeyInfo xmlns="http://www.w3.org/2000/09/xmldsig#">
<X509Data>
<X509Certificate>123</X509Certificate>
</X509Data>
</KeyInfo>
</KeyDescriptor>
<KeyDescriptor use="signing">
<KeyInfo xmlns="http://www.w3.org/2000/09/xmldsig#">
<X509Data>
<X509Certificate>123</X509Certificate>
</X509Data>
</KeyInfo>
</KeyDescriptor>
<KeyDescriptor use="signing">
<KeyInfo xmlns="http://www.w3.org/2000/09/xmldsig#">
<X509Data>
<X509Certificate>123</X509Certificate>
</X509Data>
</KeyInfo>
</KeyDescriptor>
<fed:TargetScopes>
<wsa:EndpointReference xmlns:wsa="http://www.w3.org/2005/08/addressing">
<wsa:Address>https://sts.windows.net/123/</wsa:Address>
</wsa:EndpointReference>
</fed:TargetScopes>
<fed:ApplicationServiceEndpoint>
<wsa:EndpointReference xmlns:wsa="http://www.w3.org/2005/08/addressing">
<wsa:Address>https://login.microsoftonline.com/123/wsfed</wsa:Address>
</wsa:EndpointReference>
</fed:ApplicationServiceEndpoint>
<fed:PassiveRequestorEndpoint>
<wsa:EndpointReference xmlns:wsa="http://www.w3.org/2005/08/addressing">
<wsa:Address>https://login.microsoftonline.com/123/wsfed</wsa:Address>
</wsa:EndpointReference>
</fed:PassiveRequestorEndpoint>
</RoleDescriptor>
<IDPSSODescriptor protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol">
<KeyDescriptor use="signing">
<KeyInfo xmlns="http://www.w3.org/2000/09/xmldsig#">
<X509Data>
<X509Certificate>123</X509Certificate>
</X509Data>
</KeyInfo>
</KeyDescriptor>
<KeyDescriptor use="signing">
<KeyInfo xmlns="http://www.w3.org/2000/09/xmldsig#">
<X509Data>
<X509Certificate>123</X509Certificate>
</X509Data>
</KeyInfo>
</KeyDescriptor>
<KeyDescriptor use="signing">
<KeyInfo xmlns="http://www.w3.org/2000/09/xmldsig#">
<X509Data>
<X509Certificate>123</X509Certificate>
</X509Data>
</KeyInfo>
</KeyDescriptor>
<KeyDescriptor use="signing">
<KeyInfo xmlns="http://www.w3.org/2000/09/xmldsig#">
<X509Data>
<X509Certificate>123</X509Certificate>
</X509Data>
</KeyInfo>
</KeyDescriptor>
<KeyDescriptor use="signing">
<KeyInfo xmlns="http://www.w3.org/2000/09/xmldsig#">
<X509Data>
<X509Certificate>123</X509Certificate>
</X509Data>
</KeyInfo>
</KeyDescriptor>
<KeyDescriptor use="signing">
<KeyInfo xmlns="http://www.w3.org/2000/09/xmldsig#">
<X509Data>
<X509Certificate>123</X509Certificate>
</X509Data>
</KeyInfo>
</KeyDescriptor>
<KeyDescriptor use="signing">
<KeyInfo xmlns="http://www.w3.org/2000/09/xmldsig#">
<X509Data>
<X509Certificate>123</X509Certificate>
</X509Data>
</KeyInfo>
</KeyDescriptor>
<SingleLogoutService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect" Location="https://login.microsoftonline.com/123/saml2" />
<SingleSignOnService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect" Location="https://login.microsoftonline.com/123/saml2" />
<SingleSignOnService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location="https://login.microsoftonline.com/123/saml2" />
</IDPSSODescriptor>
</EntityDescriptor>
Wesley Barroso Lopes via Plone Community wrote at 2024-6-20 21:47 +0000:
@dieter I think I figured out what the problem is. The SAML2 response certificate is not in the metadata xml registered in the SP. Is this an error?
At least, it is not what dm.saml2 (used by dm.zope.saml2)
expects.
If you look at dm.saml2.signature.SignatureContext.verify
(--> "now verify the signature: try each key in turn"),
you will see that it tries the verification for each key
known by its "KeysManager". If there is no such key VerifyError
is raised.
dm.zope.saml2 has set up
the "KeysManager" to contain the certificates from the metadata.
Thus, the SP metadata not containing a certificate explains
the error you observe.
Have you ever seen a situation like this? The IdP is Microsoft 365.
I have never worked with a Microsoft IDP.
I have worked with SAML entities which do not provide metadata
or provide inadequate metadata.
A workaround in this case: provide (fixed) metadata in a file
and integrate the entity with a "file:" URL pointing to this file.
Wesley Barroso Lopes via Plone Community wrote at 2024-6-20 22:19 +0000:
In fact, XML comes with several certificates, but none are the ones from the SAML response. Could it be that the certificate is out of date in some configuration? Below is the metadata XML modified to hide data:
The part retained below from your metadata citation
seems to indicate that the metadata does contain certificate information.
...
123
The X509Certificate element contains the certificate
(even though 123 is definitely not a valid certificate).
Thus, the assumption from your previous post (metadata not containing
certificates) seems wrong
(and the error you observe is still not yet understood).
One suggestion is that the error message contains something like "perhaps the metadata xml does not contain the SAML response certificate".
Can you provide an example of metadata xml that works with dm.zope.saml2?
That's what I said in my previous post. It has several certificates. But none is the certificate that comes in the SAML response. So validation doesn't work.
Wesley Barroso Lopes via Plone Community wrote at 2024-6-21 12:41 +0000:
...
That's what I said in my previous post. It has several certificates. But none is the certificate that comes in the SAML response. So validation doesn't work.
Apparently, you lack some SAML background (and I have not recognized this
before):
the SAML messages (apart from the metadata) usually do not contain
certificates.
Those messages may have been signed with a (private) key;
they can be verified with a certificate associated with this key.
An SAML entity lists in its metadata which certificates might
be able to verify the messages it has signed.
In your special case:
the MS IDP has listed in its metadata certificates associated
with the (private) keys it is using for signing the SAML responses.
That the verrification nevertheless fails indicates some non-obvious problem.
We need more detailed error information to understand this problem.
Have you checked whether you can activate the
"error details" mechanism of dm.xmlsec.binding?
For this, you download a source distribution of dm.xmlsec.binding
and call python setup.py test in its top level drrectory.
If this does not crash, the mechanism can be used in your environment.
If it can be used, use it to get details about your verification
failures.
Yes, I don't understand much about SAML2. I did a test with a SAML2 mock (https://mocksaml.com) and in it the certificate that comes in the SAML response is in the metadata. And in this test, the validation worked. So I deduced that the certificate would need to be in the metadata. I know it works that way. The way you said it doesn't seem to work in my case, or the metadata is wrong.
That didn't work. Server crashed when calling verify_ctx.verify(sig)
Wesley Barroso Lopes via Plone Community wrote at 2024-6-21 14:13 +0000:
...
That didn't work. Server crashed when calling
verify_ctx.verify(sig)
I just published a new version of dm.xmlsec.binding
("dm.xmlsec.binding · PyPI").
It will not solve your verification problem but it should
make it possible to obtain corresponding error details
(read section "Obtaining error information" of
"dm.xmlsec.binding · PyPI").
Ensure you are using a non binary lxml distribution
(read section "Installation --> Python level requirements"
of dm.xmlsec.binding · PyPI").
Using a binary lxml distribution can lead to memory corruption
and a crash (python setup.py test will crash somewhere
in XmlDocCopyNode with a binary lxml distribution).