Improved error handling of misspelled IDPEndpoint ID

[JornWildt]

One often occuring issue we see when installing OIOSAML based applications, is that the ID of an added IDPEndpoint is mispelled - leading to a situation where it cannot find the default IDPEndpoint. The endpoint is created, since it is added manually in the config file, but the metadata file is not found - resulting in an internal NULL pointer reference, which in turn leaves the person installing it without any clue about what is wrong.

Please make a very visible error message for this kind of situation, explaining what is wrong.

We have solved it by adding this check in SAML20FederationConfig:

    internal void Initialize()
        if (MetadataLocation == null)
            return;

        if (!Directory.Exists(MetadataLocation))
            throw new DirectoryNotFoundException(string.Format(Resources.MetadataLocationNotFound, MetadataLocation));

        string[] files = Directory.GetFiles(MetadataLocation, "*.config");
        foreach (string file in files)
        {
            HandleCreateIdp(file);
        }

        // CHECK METADATA FILE
        foreach (var idp in IDPEndPoints)
        {
            if (idp.metadata == null)
              throw new InvalidDataException($"The IDPEndpoint refering to id \"{idp.Id}\" does not have a corresponding metadata file.");
        }

[thomasnymand]

Addressed in #82 .

When the id of a configured IDPEndpoint is misspelled, no metadata file matches it, so the endpoint's metadata stays null. When that endpoint was the selected default, RetrieveIDP returned it and the caller hit an opaque NullReferenceException, the "no clue what's wrong" situation you described.

RetrieveIDP now throws a descriptive Saml20Exception naming the offending id.

A note on the approach: your suggested fix throws exception inside IDPEndpoints.Initialize(). Code deliberately checks at point-of-use instead, because the test configuration intentionally declares endpoints without matching metadata files, and Initialize() runs on every config load. Validating when the endpoint is actually selected gives the same clear error to someone setting up an integration, without that side effect.

Thanks for the detailed report and the example fix!