Fixes #227

Problem

When a SAML assertion carries an attribute that exists but has no real value, node-saml currently loses that information in profile.attributes:

• An attribute with no AttributeValue child at all, for example <saml2:Attribute Name="employee_id"/>, is dropped from profile.attributes entirely. Google Workspace emits these in the wild.
• An attribute whose AttributeValue is present but empty, for example <AttributeValue/> with xsi:type="xs:string", comes back as undefined.

In both cases a consumer cannot tell a valueless attribute apart from one the IdP never sent: {} and { employee_id: null } should not collapse to the same thing.

The SAML 2.0 Core spec is explicit about both shapes:

• Section 1219: within an <AttributeStatement>, if the SAML attribute exists but has no values, the <AttributeValue> element MUST be omitted. The attribute itself still exists.
• Section 1246: if a SAML attribute includes an empty value such as the empty string, the corresponding <AttributeValue> element MUST be empty (serialized as <AttributeValue/>).

Fix

src/saml.ts attribute extraction now keeps these attributes instead of discarding them:

• No AttributeValue child is represented as null (the attribute exists, no value).
• An empty AttributeValue is represented as the empty string "" rather than undefined, matching the xs:string empty-value semantics from section 1246.

Populated single-value, object-valued (nested NameID), and multi-valued attributes are parsed exactly as before. The single-value-versus-array branch is untouched.

Before / after

For <saml2:Attribute Name="employee_id"/>:

• before: profile.attributes does not contain employee_id
• after: profile.attributes.employee_id === null

For <saml2:Attribute Name="x"><AttributeValue/></saml2:Attribute>:

• before: profile.attributes.x === undefined
• after: profile.attributes.x === ""

Tests

Added two tests under the validatePostResponse xml signature checks suite, including the exact null-attribute case from the issue:

• "An attribute with no AttributeValue should be null"
• "An empty AttributeValue should be an empty string"

Both fail on master (the first throws expected {} to have property 'attributeName', the second expected undefined to equal '') and pass with this change. I also updated the two existing tests that asserted the old drop/undefined behavior, since the issue calls that behavior out as incorrect:

• accept response with an attributeStatement element without attributeValue now expects evilcorp.roles to be present as null.
• the former An undefined value given with an object should still be undefined is renamed to An empty AttributeValue should be an empty string and asserts "".

Full suite is green (273 passing), and lint and prettier pass on the changed files.

Compatibility note

This is a behavior change for consumers that relied on valueless attributes being absent or undefined, so it fits a semver-major release. That lines up with the breaking-change release discussed in the issue thread.

Summary by CodeRabbit

• Bug Fixes

  • Improved SAML attribute handling to properly preserve missing attributes with null values instead of omitting them.
  • Fixed attribute value mapping to correctly return empty strings for empty AttributeValue nodes.

• Tests

  • Updated test cases to validate new SAML attribute processing behavior.