InCommon metadata support

[Shannon Roddy <>]

On 9/21/17 1:43 PM, Patrick Krogel wrote:
> 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.

Hi Patrick,

I went through the archive of the published metadata, and the history of
the entityID, and it looks like it wouldn't have been possible that the
:443 entityID was published.  When the entityID was initially created
(Feb 14th, 2017), it was previously rejected with the :443 on the 13th,
and then approved once the port was removed.  So, from the date of
initial publishing it would have been of the form
entityID="https://sso.mtu.edu/idp/shibboleth";.


> 
> The odd thing is that it was just the Federated SPs that were affected. 

Do you have access to any of the SP logs?  Is it possible the SP
reporting the :443 was unable to retrieve the published metadata on the
15th, and then fell back to some local/stale metadata?

Best,
Shannon

> 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 
> <
> <mailto:>>
>  wrote:
> 
>     On 9/21/17, 8:42 AM, 
> "
>     
> <mailto:>
>  on behalf of
>     
> 
>  
> <mailto:>"
>     
> <
>     
> <mailto:>
>  on behalf of
>     
> 
>  
> <mailto:>>
>  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 <http://www.mtu.edu>
> www.it.mtu.edu <http://www.it.mtu.edu>