The HttpRedirectBindingBuilder.SigningKey setter allows for null values.

                // Check if the key is of a supported type. [SAMLBind] sect. 3.4.4.1 specifies this.
                if (!(value is RSACryptoServiceProvider || value is DSA || value == null))
                {
                    throw new ArgumentException("Signing key must be an instance of either RSACryptoServiceProvider or DSA.");
                }

This expression which is used to assign to that property fails if the ServiceProvider does not have a SigningCertificate.

                    SigningKey = config.ServiceProvider.SigningCertificate.PrivateKey,

Added the Elvis operator to implement this.

                    SigningKey = config.ServiceProvider.SigningCertificate?.PrivateKey,

…nseChallengeAsync

The current default is currentUri which does not seem like the best choice if a value for RedirectAfterLogin is available.

I was expecting the browser to be redirected to RedirectAfterLogin post authentication but I actually saw an endless loop of authentications because it was redirecting to currentUri.

…s of type SecurityTokenServiceType and ApplicationServiceType which were not expected. There was a workaround which involved removing those but that also meant that the signature had to be removed. I added types which allows the metadata to be deserialized - even if there is no special handling for them.

The certificates in the SAML response were being passed in a way that the existing code did not expect. They are now parsed successfully.

…se it was a hash of the whole document that was being used instead of one based on just the assertion.

…ions.