there has been a report on incident-response at idpy.org about a security
issue in PySaml2.
Alexey Sintsov and Yuri Goltsev from HERE Technologies reached out and
reported a XML Signature Wrapping (XSW) vulnerability. The issue
affects responses with signed assertions. PySaml2 can be tricked to
think that an assertion had been signed and use the assertion
information, when in reality the Signature points to another part of
the xml document that is controlled by another party.
The issue was assigned CVE-2020-5390 and is now fixed in the latest
The relevant code commit that fixes is the issue:
Release v5.0.0 contains more changes, including:
- Add freshness period feature for MetaDataMDX
- Fix ipv6 validation to accommodate for addresses with brackets
- Fix xmlsec temporary files deletions
- Add method to get supported algorithms from metadata
- Add mdstore method to extract assurance certifications
- Add mdstore method to extract contact_person data
- Start dropping python2 support
Pointers to the release with changelog and more information, below:
- the relevant release commit:
- the github release:
- the pypi package:
+ + + + + + + +
In more detail, regarding the XSW vulnerability:
libxml2 follows the xmldsig-core specification. The xmldsig
specification is way too
general. saml-core reuses the xmldsig specification, but constrains it to use of
specific facilities. The implementation of the SAML specification is
enforce those constraints. libxml2/xmlsec1 are not aware of those
constraints and thus
process the document based on the full/general xmldsig rules.
What is happening is the following:
- xmldsig-core allows the signature-information and the data that was
signed to be in
different places. This works by setting the URI attribute of the
The URI attribute contains an optional identifier of the object
being signed. (see
"4.4.3 The Reference Element" --
This identifier is actually a pointer that can be defined in many
different ways; from
XPath expressions that need to be executed(!), to a full URL that
should be fetched(!)
in order to recalculate the signature.
- saml-core section "5.4 XML Signature Profile" defines constrains on
facilities. It explicitly dictates that enveloped signatures are the
allowed. This mean that:
* Assertion/RequestType/ResponseType elements must have an ID attribute
* signatures must have a single Reference element
* the Reference element must have a URI attribute
* the URI attribute contains an anchor
* the anchor points to the enclosing element's ID attribute
xmlsec1 does the right thing - it follows the reference URI pointer
and validates the
assertion. But, the pointer points to an assertion in another part of
the document; not
the assertion in which the signature is embedded/enveloped. SAML
processing thinks that
the signature is fine (that's what xmlsec1 said), and gets the
assertion data from the
assertion that contains the signature - but that assertion was never
issue is that pysaml2 does not enforce the constrains on the signature
facilities of xmldsig-core, that the saml-core spec defines.
The solution is simple; all we need is to make sure that assertions
with signatures (1)
contain one reference element that (2) has a URI attribute (3) that is
an anchor that
(4) points to the assertion in which the signature is embedded. If
those conditions are
met then we're good, otherwise we should fail the verification.
Ivan c00kiemon5ter Kanakarakis >:3
Hola a todos!
As described in the Statues of IdentityPython , roughly half the seats for the idpy Board are opening for nominations. The following members have completed their one-year terms:
Ivan Kanakarakis (current chair)
Roland Hedberg (at-large)
They are all eligible to be nominated again for a new board term.
The term for these seats is now shifting to a two-year cycle, such that half the board will be up for nomination each year.
Participants on the idpy-dev list act as the nominating committee for the idpy board. If you would like to nominate someone (or self-nominate) please contact me directly no later than 24 January 2020.
Thank you for your time and consideration,
 Excerpt from the Statutes of IdentityPython (https://dracc.commonsconservancy.org/0024/ <https://dracc.commonsconservancy.org/0024/>)
Board of Directors
The central decision-making body within IdentityPython is the IdentityPython Board of Directors (in short: the IdentityPython Board). The IdentityPython Board is a committee responsible for making and coordinating decisions on behalf of the user and developer community around IdentityPython, according to the conditions set forth in these Statutes as well as any Regulations established by prior decisions of the IdentityPython Board. The IdentityPython Board is expected to consult and find consensus for decisions with the user and developer community.
The IdentityPython Board has a minimum of three, and a maximum of seven natural persons. The founding IdentityPython Board has appointed a number of its constituting Directors to serve a half (12 month) term, and the remainder to serve a regular (24 month) term. Subsequent Directors are elected by the IdentityPython Board to regular 24-month terms according to the procedure set out in these Statutes. The founding Board will select a nominating committee of active developers and other contributors to identify candidates for ongoing Board membership. Directors are permitted to seek office for multiple terms, however, when running against other candidates the amount of terms they have consecutively served is deducted from the votes cast in their favour. This provides a balance between continuity, equal opportunities and renewal of qualities and competences.
The IdentityPython Board determines the Programme's structure and processes, and is responsible for maintaining its Statutes and Regulations. The IdentityPython Board is free to make or revise any decision, taking into consideration applicable law as well as any immutable conditions previously established within the Statutes or Regulations.
In order to efficiently fulfill its tasks, the Board may establish specialized committees and task forces, as well as assign named roles to qualified individuals to provide advice and assistance on specific issues. The associated qualifications, tasks and responsibilities SHALL be formalised by publication as part of the Regulations of IdentityPython.
The IdentityPython Board (and any person, group or organisation mandated by the IdentityPython Board on its behalf) must act in good faith and in the common interest of the developer community and the wider user community of IdentityPython. If significant harm to the organization has been committed by any Director, he or she MAY be removed from the Board by a simple majority vote of the rest of the Board.
The IdentityPython Board SHALL convene offline or online at least every twelve (12) months.
It was mentioned in the notes from the idpy dev call, 17 December 2019.
The higher up you go, the more mistakes you are allowed. Right at the top, if you make enough of them, it's considered to be your style.
-Fred Astaire, dancer, actor, singer, musician, and choreographer (10 May 1899-1987)
I'm happy to announce the first official release of uniAuth (v1.0.0), a
SAML2 IdP based on Django and pySAML2.
Next minor releases will focus on the updates coming from pySAML2.
Next major releases will introduce OIDC through django-oidc-op
Thank you idpy community
Dott. Giuseppe De Marco
CENTRO ICT DI ATENEO
University of Calabria
87036 Rende (CS) - Italy
Phone: +39 0984 496961
e-mail: giuseppe.demarco at unical.it