Support parsing full nano second IssueInstant

[jej2003]

The IdP we are integrating with is responding with a SAML Response with IssueInstant having 9 digits of second precision. I do not have the ability to modify the IdP unfortunately do not see a way to ignore the additional digits in this library. I am looking for a workaround for how to gracefully handle these responses as they currently cause the Assertion to be rejected. Any guidance for how to best work around this issue would be fantastic! Current stack trace is provided

2025-03-06 16:18:06.598 +00:00 [Debug] (Sustainsys.Saml2.AspNetCore2.Saml2Handler) Signature validation passed for Saml Response _f1ea718e-eabf-491f-a0fe-da1f84242499 
2025-03-06 16:18:06.621 +00:00 [Error] (Wkc.Cbw.Web.Middleware.HttpStatusCodeExceptionMiddleware) Http Status Code Exception Middleware "IDX13102: Exception thrown while reading '[PII is hidden]' for Saml2SecurityToken. Inner exception: 'System.FormatException'." 
Microsoft.IdentityModel.Tokens.Saml2.Saml2SecurityTokenReadException: IDX13102: Exception thrown while reading '[PII is hidden]' for Saml2SecurityToken. Inner exception: 'System.FormatException'.
---> System.FormatException: String '2025-03-06T16:18:06.642345458Z' was not recognized as a valid DateTime.
  at Sustainsys.Saml2.Saml2P.Saml2PSerializer.ReadAssertion(XmlReader reader)
  --- End of inner exception stack trace ---
  at Sustainsys.Saml2.Saml2P.Saml2PSerializer.ReadAssertion(XmlReader reader)
  at Microsoft.IdentityModel.Tokens.Saml2.Saml2SecurityTokenHandler.ReadSaml2Token(String token)
  at Sustainsys.Saml2.Saml2P.Saml2PSecurityTokenHandler.ValidateToken(String token, TokenValidationParameters validationParameters, SecurityToken& validatedToken)
  at Sustainsys.Saml2.Saml2P.Saml2Response.CreateClaims(IOptions options, IdentityProvider idp)+MoveNext()
  at System.Collections.Generic.List`1..ctor(IEnumerable`1 collection)
  at System.Linq.Enumerable.ToList[TSource](IEnumerable`1 source)
  at Sustainsys.Saml2.Saml2P.Saml2Response.GetClaims(IOptions options, IDictionary`2 relayData)
  at Sustainsys.Saml2.WebSso.AcsCommand.ProcessResponse(IOptions options, Saml2Response samlResponse, StoredRequestState storedRequestState, IdentityProvider identityProvider, String relayState)
  at Sustainsys.Saml2.WebSso.AcsCommand.Run(HttpRequestData request, IOptions options)
  at Sustainsys.Saml2.AspNetCore2.Saml2Handler.HandleRequestAsync()
  at Microsoft.AspNetCore.Authentication.AuthenticationMiddleware.Invoke(HttpContext context)
  at Microsoft.AspNetCore.Session.SessionMiddleware.Invoke(HttpContext context)
  at Microsoft.AspNetCore.Session.SessionMiddleware.Invoke(HttpContext context)
  at Wkc.Cbw.Web.Middleware.HttpStatusCodeExceptionMiddleware.Invoke(HttpContext context) in /src/Wkc.Cbw.Web/Middleware/HttpStatusCodeExceptionMiddleware.cs:line 58

[jej2003]

On further review it is more than just the IssueInstant on the Response, it's on Assertions, and Conditions NotBefore attributes. Making any changes to the XML so that the it is compliant doesn't work because that then invalidates the signature (makes sense of course).

[joshuafranklinengineeringsystems]

The issue you’re encountering stems from the IssueInstant in the SAML response, which includes fractional seconds with excessive precision (2025-03-06T16:18:06.642345458Z). The .NET DateTime type typically supports up to 7 digits (100-nanosecond precision) but not 9 digits, resulting in the parsing error. Neutral (Consensus) View: This issue arises because the Sustainsys.Saml2 library (and underlying .NET parsing) expects SAML datetime strings compliant with the XML Schema (xs:dateTime) standard, which typically supports up to 7 digits of fractional seconds (100-nanosecond precision). Your Identity Provider (IdP) is providing additional precision (nanoseconds), causing a FormatException. Recommended Workaround (Neutral): Because you can’t modify the IdP, the pragmatic workaround is to intercept the raw SAML response before the Sustainsys library processes it, manually strip or truncate the fractional seconds to a valid precision, and then pass it along. Here’s how you might approach it practically: Practical Workaround: You can create a custom middleware or modify your existing SAML response handling to intercept and rewrite the problematic timestamp: Example (Middleware in C#): public class SamlTimestampCorrectionMiddleware {     private readonly RequestDelegate _next;     public SamlTimestampCorrectionMiddleware(RequestDelegate next)     {         _next = next;     }     public async Task Invoke(HttpContext context)     {         context.Request.EnableBuffering();         if (context.Request.Path.StartsWithSegments("/Saml2/Acs") &&             context.Request.Method == HttpMethods.Post &&             context.Request.HasFormContentType)     {         var form = await context.Request.ReadFormAsync();         var samlResponse = form["SAMLResponse"].FirstOrDefault();         if (!string.IsNullOrEmpty(samlResponse))         {             var decodedXml = Encoding.UTF8.GetString(Convert.FromBase64String(samlResponse));             // Adjust precision of IssueInstant timestamps             var correctedXml = Regex.Replace(                 decodedXml,                  @"(\d{4}-\d{2}-\d{2}T\d{2}:\d{2}:\d{2}\.\d{7,}Z)",                  match => TruncateTimestamp(match.Value)             );             var encodedCorrectedResponse = Convert.ToBase64String(Encoding.UTF8.GetBytes(decodedXml));             // Create new form collection             var correctedForm = new Dictionary<string, StringValues>(form)             {                 ["SAMLResponse"] = encodedCorrectedResponse             };             context.Request.Form = new FormCollection(correctedForm);         }     }     await _next(context); } private string TruncateTimestamp(string originalTimestamp) {     // Ensure the timestamp has no more than 7 fractional second digits     var dotIndex = original.IndexOf('.');     if (dotIndex >= 0 && original.EndsWith("Z"))     {         var fractionalPart = original.Substring(dotIndex + 1).TrimEnd('Z');         var truncatedFractional = fractionalPart.Length > 7 ? fractionalPart.Substring(0, 7) : fractionalPart;         return original.Substring(0, dotIndex + 1) + truncatedFractional + "Z";     }     return original; } Registration in Startup.cs: app.UseMiddleware<SamlTimestampCorrectionMiddleware>(); This middleware intercepts the SAML response, decodes it, adjusts the timestamp precision, and re-encodes it, making it compatible with the Sustainsys library. Opinion: • Consensus View: The proper fix is typically to address this issue at the IdP side. SAML responses should adhere strictly to the standards (RFC3339 or XML Schema standards), which prevents downstream integration issues. Given that you can’t modify the IdP, the middleware approach is the best practical solution. • Alternate Viewpoint (Devil’s Advocate): From a purist standpoint, altering a signed assertion is generally not ideal since it can potentially invalidate the XML signature. While the timestamp change may not invalidate the signature if whitespace and exact formatting are preserved, there’s still a risk. Thus, always test thoroughly. Further Considerations: • XML Signature Validation: Altering the SAML XML response could invalidate the digital signature, causing validation failures. Test to confirm signature integrity is maintained. • Performance: Ensure this middleware doesn’t significantly affect the response time of your authentication flow. • Maintenance: Clearly document this workaround in your code, indicating that it’s a temporary or workaround solution, not a permanent fix. • Communication: It’s advisable (if feasible) to escalate to the IdP maintainers that their timestamp precision violates common standards.Alan TaylorDirector,  Software Engineer+44 7768 831597Joshua Franklin Engineering Systems LimitedRegistered Office: Flat 2 Grove Court, 9 Gumbrell Mews, REDHILL, RH1 1TGVAT Registration Number: 440 7683 87Registered Number: 14299506Registered in England & WalesOn 6 Mar 2025, at 17:50, Jamie ***@***.***> wrote: On further review it is more than just the IssueInstant on the Response, it's on Assertions, and Conditions NotBefore attributes. Making any changes to the XML so that the it is compliant doesn't work because that then invalidates the signature (makes sense of course).—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you are subscribed to this thread.Message ID: ***@***.***> jej2003 left a comment (Sustainsys/Saml2#1489) On further review it is more than just the IssueInstant on the Response, it's on Assertions, and Conditions NotBefore attributes. Making any changes to the XML so that the it is compliant doesn't work because that then invalidates the signature (makes sense of course). —Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[jej2003]

This is nearly what I am doing except there are dates in other portions of the Response as well and making the changes mentioned (IssueInstant on Assertions and NotBefore on Conditions) invalidates the signature. As a hack I was wondering if it was possible to disable signature validation to see what else may be of issue.

[AndersAbel]

Disabling signature validation is a really bad idea - it would just invalidate the entire security of Saml2.

The good news is that this is one of those weird situations that I decided to be able to handle in the next (v3) version of the library. It contains a much more flexible XML parser that can supress errors or override reading of specific values. A quick test shows that the data type conversions are not designed to be replaceable in there. However, there is a mechanism to ignore errors and from in there it is also possible to run custom code that recovers from the error. So that would be possible to use to work around the parsing problem.

v3 is unfortunately not done and available for usage yet. What is your time frame, when do you need this?

[AndersAbel]

@joshuafranklinengineeringsystems The response you added looks very much AI generated - is that the case?

It even points out the problem with the suggested solution, although it doesn't really get it right.

Altering the SAML XML response could invalidate the digital signature, causing validation failures. Test to confirm signature integrity is maintained.

If the XML is altered, the signature will be invalidated. If you've found a way to change the contents and keep the integrity of the signature, you've found a way to circumvent Saml2 security completely.

[jej2003]

Frankly my hope is to talk to the provider of the IdP to address this, but I am not sure they will or will not budge. Is my reading of the spec correct that millisecond precision is the requirement?

Timeline is likely in the next 3 months needing to have a solution, obviously subject to be shot down by the program lead now that I've said it! Is there a timeline in which you're looking to have v3 ready for general availability?

[jej2003]

Reading the specification it's clear the authors recommendation regarding time resolution finer than milliseconds (SAML system entities SHOULD NOT rely on time resolution finer than milliseconds), however this appears to be the only place in the code base where the library is strict regarding the use of DateTime.ParseExact vs the more forgiving DateTime.Parse. Is there a reason for the different handling of DateTime here from other portions of the library? Would it be reasonable to use DateTime.Parse instead of ParseExact in this situation as well?

[jej2003]

I created this PR to make the change I was referencing. I tested this locally for my use case and it appears to have addressed the issue I was running into. I am admittedly not a dotnet guy though so if I missed something please let me know. Thanks again for the support and the great library!

[jej2003]

Circling back to see if there’s any appetite to address this prior to the next major release?

[AndersAbel]

I've tried to look in the commit history to find out why this specific instance use ParseExact. However, there are no commit comments that help so far. The existing code enforces allowed formats. Relaxing that to not enforce a format might have security implications that must be understood before doing any changes.

The immediate thing I can think of here is to ensure/enforce that all times are in UTC format. For a single, specific Idp I guess it would be fine to relax the validation, but doing it in the general library would require much more analysis before to ensure no security issue is introduced by the change.

So, my conclusion for this is that the v3 design idea likely remains, where this will not be supported out of the box, but where it will be easy to add an event that can recover from the errors.

For v2, I'm only doing security fixes unless the work is part of commercial support. This does not look like a security issue to me. If you would like to discuss commercial options, please reach out to support@sustainsys.com

[jej2003]

That’s unfortunate but understood. I will discuss potential commercial support with my lead and reach out if that is an option for the program. Is there a time line for v3?

[AndersAbel]

@jej2003 Please mail me to discuss v3 timeline. The timeline for having something available depends on what features you need. Getting something out that supports a basic Saml2 handshake shouldn't be too far away.