v2.3.8

Release note:

#173 Fix the wrong property for name id format
#170 #176 Update documentation for breaking change of API >= 2.0
#174 Fix syntax error of type definition in libsaml module
#187 Use npm published package instead of github repo link
#190 Expose InResponseTo in parseLoginResponse extract (@benbabic)

9dc7460 Put type definitions back to dependencies list
1d78763 Update the testing scope of different node version

The current testing build for Node.js v10 is broken, we will seek for a fix in next release very soon.

v2.3.7

Release Note

#167 Upgrade to the latest stable release version of node-forge (0.7.4) in order to get the fix of the CVE.
#153 (PR #161) Fix the empty reference URI (@wwindcloud)

Remarks:

For the issue #167, xml-encryption also uses node-forge. However, since there is no update since we sent the PR two weeks ago, we force to use the fork version which upgrades the node-forge to 0.7.4 first, once they merge the PR, we will change back to use the official one.

https://github.com/tngan/samlify/blob/master/package.json#L45

v2.3.6

Release Note

#150 UTF-8 encoding for decoding response with special character (@kiejo)

Remarks:

The policy for releasing new version is in weekly based. If any pull request is being merged, new commits are done for enhancements and bug fixes within that week, those are grouped in one patch and released to npm registry before 15:00 UTC on friday.

v2.3.5

Release note

#142 Fix build error (@killalau)
#146 Patches for correcting namespace usage (@wwindcloud)
#129 Some updates on the window installation

We don't support Node v7 and support v9 starting from v2.3.5.

v2.3.4

Release note

#140 Fix missing build context
#139 Fix and enhancement on key descriptor usage (Credit to @wwindcloud)
#133 Dynamic namespace assignment for signature and key data
#138 Try to fix the unstable xsd validation result and test build

Remove yarn.lock and CHANGELOG.md

v2.3.3

Release note

This release is just a minor patch. Thanks @gtothesquare for resolving two issues.

#135 Fix multiple key descriptor issues (possibly fix #117)
#137 Add SessionIndex to the parser

v2.3.0

Release Note

#119 Trim space in certificate string (7173238, contributed by @ahwitz)
#121 Response xsd schema validation (reported by @thijsschoonbrood)

Reference: https://www.whitehats.nl/blog/xml-signature-wrapping-samlify

This release includes a fix for potential security risk reported by @thijsschoonbrood from WhiteHats B.V., all versions before samlify v2.2.0 basically accepts any kind of response without a schema validation, and the xpath we used to fetch the xml element is in relative path, so that it could expose to MITM attack in the following form:

<saml:NameID>evil@evil.com</saml:NameID>
<samlp:Response>
  <saml:Assertion>
    <saml:NameID>good@good.com</saml:NameID>
  </saml:Assertion>
</samlp:Response>

const { samlContent, extract } = await sp.parseLoginResponse(idp, 'post', req);

The parsed result in extract.nameid object would have an array consists of evil@evil.com and good@good.com. samlify is designed to parse essential fields and leave the validation to users, the false nameid (or other sensitive fields) can be accepted unless the validation is done properly on developer side.

A test is made and an error is expected to be thrown. Error: Element 'NameID': No matching global declaration available for the validation root.

The first approach is to add response xsd schema validation, and the next step would be refactor of the usage of xpath and introduce common validations (#111, #126), such as time validation.

v2.2.0

Release Note

v2.1.1

Release note

#108 A patch to parse and normalize the given x509Certificate string in SAML response

v2.1.0

Release note

• #102 Add support for relay state in SAML request (@puneetmakkar)
• #100 Key matching scheme for signing certificates
• #99 Updating checkSignature spellings (@puneetmakkar)

This release includes a new important feature (#100). Multiple signing certificates in metadata is allowed in SAML2 specification, some IdP might choose to roll the usage of different keys, therefore, service provider should be able to check if the one specified in SAML response is already specified in the metadata, it's just like a whitelist checking and an error will be thrown if there is no matching key. Last but not least, thanks for @puneetmakkar your two pull requests as well.