InCommon metadata support

[Patrick Krogel <>]

I wasn't trying to fix my IdP's metadata.  I hadn't heard about the entityID mismatch until days later.  I was going off the assumption that the InCommon SP data had gotten corrupted.  I had tried stopping and restarting our IdP, but it had no effect.  The next thing I came up with was downloading a new copy of the InCommon SP metadata and restarting the server again.

I suppose I was suggesting that maybe InCommon had accidentally published our old entityID with the :443 in it.  The Federated SPs would then be expecting the :443 in the entityID, but we were responding without it.  The entityID could have been fixed and re-published, just happening to correspond to the time I made my change and restarted our IdP.

The odd thing is that it was just the Federated SPs that were affected.  If we were really giving out the wrong entityID, then the other SPs should also have been affected.

On Thu, Sep 21, 2017 at 11:47 AM, Cantor, Scott <> wrote:

On 9/21/17, 8:42 AM, " on behalf of " < on behalf of > wrote:

> I ended up downloading a new InCommon metadata file and restarting our IdP
> (since just restarting didn't change anything.)  That was around 5pm and
> appeared to fix it.  I was just wondering if I had actually fixed it, or it
> was just a coincidence that it started working again.

As a matter of simple functional explanation, you cannot correct a problem that may exist in your IdP's metadata by changing the metadata your idP uses. Your IdP doesn't consume its own metadata.

If the problem was in an SP's metadata, then obviously reloading it and changing the metadata the IdP uses is a very different matter.

What seems more likely is that your system broke in some way and restarting it corrected that.

-- Scott

--

Patrick Krogel

Senior Application Systems Analyst

Information Technology

Michigan Technological University

(906)487-1486

www.mtu.edu

www.it.mtu.edu