Skip to content

Output a valid XML dateTime for the validUntil metadata property#638

Merged
pitbulk merged 1 commit intoSAML-Toolkits:masterfrom
agrobbin:metadata-validuntil-strftime
Jan 2, 2023
Merged

Output a valid XML dateTime for the validUntil metadata property#638
pitbulk merged 1 commit intoSAML-Toolkits:masterfrom
agrobbin:metadata-validuntil-strftime

Conversation

@agrobbin
Copy link
Copy Markdown
Contributor

@agrobbin agrobbin commented Jun 8, 2022

The XML generated prior to this change was considered invalid, according to samltool.com's XML validator. An example metadata XML document:

<md:EntityDescriptor xmlns:md="urn:oasis:names:tc:SAML:2.0:metadata" ID="_a881df95-a3e4-43df-a340-47742de4c356" entityID="..." validUntil="2022-06-15T03:03:01+0000">
<md:SPSSODescriptor AuthnRequestsSigned="false" WantAssertionsSigned="true" protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol">
<md:NameIDFormat>urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress</md:NameIDFormat>
<md:AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location="..." index="0" isDefault="true"/>
</md:SPSSODescriptor>
</md:EntityDescriptor>

The +0000 is the culprit, with the following validation error received from samltool.com:

Line: 1 | Column: 0  --> Element '{urn:oasis:names:tc:SAML:2.0:metadata}EntityDescriptor', attribute 'validUntil': '2022-06-15T03:03:01+0000' is not a valid value of the atomic type 'xs:dateTime'.

Additionally, should someone pass a non-UTC time for validUntil, that also produced invalid XML.

Now, we coerce the provided validUntil into a UTC time, and hard-code a Z at the end of the format, to consistently produce valid XML.

The XML generated prior to this change was considered invalid, according to samltool.com's XML validator. An example metadata XML document:

```xml
<md:EntityDescriptor xmlns:md="urn:oasis:names:tc:SAML:2.0:metadata" ID="_a881df95-a3e4-43df-a340-47742de4c356" entityID="..." validUntil="2022-06-15T03:03:01+0000">
<md:SPSSODescriptor AuthnRequestsSigned="false" WantAssertionsSigned="true" protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol">
<md:NameIDFormat>urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress</md:NameIDFormat>
<md:AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location="..." index="0" isDefault="true"/>
</md:SPSSODescriptor>
</md:EntityDescriptor>
```

The `+0000` is the culprit, with the following validation error received from samltool.com:

```
Line: 1 | Column: 0  --> Element '{urn:oasis:names:tc:SAML:2.0:metadata}EntityDescriptor', attribute 'validUntil': '2022-06-15T03:03:01+0000' is not a valid value of the atomic type 'xs:dateTime'.
```

Additionally, should someone pass a non-UTC time for `validUntil`, that also produced invalid XML.

Now, we coerce the provided `validUntil` into a UTC time, and hard-code a `Z` at the end of the format, to consistently produce valid XML.
@agrobbin
Copy link
Copy Markdown
Contributor Author

agrobbin commented Jun 8, 2022

The error in CI seems to be unrelated to this change (it's a JRuby OpenSSL error).

@pitbulk pitbulk changed the base branch from master to ci-coveralls January 2, 2023 21:49
@pitbulk pitbulk changed the base branch from ci-coveralls to master January 2, 2023 21:50
@pitbulk pitbulk merged commit ca2acbf into SAML-Toolkits:master Jan 2, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants