InCommon metadata support

["Hall, Gerry" <>]

For of Shannon Roddy.

1. No proxy but our two IdP’s are fronted by a load balancer with both IdP’s 
in backend pool on the F5 loadbalancer.  Public VIP is 170.140.125.23 
(login.emory.edu).
  
2.  First error entry at 3:04 PM:
10.110.29.20|2017-09-15 15:04:23,139|19806227F8B60BACA9F30207224E186D| - 
ERROR [org.opensaml.saml.metadata.resolver.impl.HTTPMetadataResolver:313] - 
Metadata Resolver FileBackedHTTPMetadataResolver InCommonMD: Error retrieving 
metadata from http://md.incommon.org/InCommon/InCommon-metadata.xml
org.apache.http.conn.HttpHostConnectException: Connect to md.incommon.org:80 
[md.incommon.org/163.253.32.9] failed: Connection refused

Last error entry at 7:18 PM:
10.110.29.20|2017-09-15 19:18:11,695|19806227F8B60BACA9F30207224E186D| - 
ERROR [org.opensaml.saml.metadata.resolver.impl.HTTPMetadataResolver:313] - 
Metadata Resolver FileBackedHTTPMetadataResolver InCommonMD: Error retrieving 
metadata from http://md.incommon.org/InCommon/InCommon-metadata.xml
org.apache.http.conn.HttpHostConnectException: Connect to md.incommon.org:80 
[md.incommon.org/163.253.32.9] failed: Connection refused

Then shows successful at 7:23 PM
10.110.29.20|2017-09-15 19:23:25,517|19806227F8B60BACA9F30207224E186D| - INFO 
[org.opensaml.saml.metadata.resolver.impl.AbstractReloadingMetadataResolver:465]
 - Metadata Resolver FileBackedHTTPMetadataResolver InCommonMD: New metadata 
successfully loaded for 
'http://md.incommon.org/InCommon/InCommon-metadata.xml'
10.110.29.20|2017-09-15 19:23:25,517|19806227F8B60BACA9F30207224E186D| - INFO 
[org.opensaml.saml.metadata.resolver.impl.AbstractReloadingMetadataResolver:306]
 - Metadata Resolver FileBackedHTTPMetadataResolver InCommonMD: Next refresh 
cycle for metadata provider 
'http://md.incommon.org/InCommon/InCommon-metadata.xml' will occur on 
'2017-09-16T05:23:15.273Z' ('2017-09-16T01:23:15.273-04:00' local time)



On 9/22/17, 1:15 PM, 
"
 on behalf of Shannon Roddy" 
<
 on behalf of 
>
 wrote:

    Hi Gerry,
    
    A couple of questions.
    
    - Do you show later in your logs the next time the metadata was
    successfully downloaded?
    - Is there a proxy configured for 10.110.29.20 or does it just rely on
    NAT for external HTTP connections?
    
    Thanks,
    Shannon
    
    
    On 9/21/17 12:12 PM, Hall, Gerry wrote:
    > I experienced the same issue with several SP’s for which the source of 
metadata is the InCommon aggregate file from about 3:28 PM until about 7:18 
PM on this past Friday 15 September.  Unfortunately, I was not made aware of 
the issue until the next day Saturday by which the issue was resolved.  I nor 
anyone on my team made any changes nor did we take any corrective action.  
Also, as the initial email  indicates, the issue only affected SP’s for which 
we rely on the InCommon aggregate file for as a source of metadata.
    > 
    >  The IdP logs had erros like the following:
    > 
    > 10.110.29.20|2017-09-15 03:27:27,382 - ERROR 
[org.opensaml.saml.metadata.resolver.impl.HTTPMetadataResolver:313] - 
Metadata Resolver FileBackedHTTPMetadataResolver InCommonMD: Error retrieving 
metadata from http://md.incommon.org/InCommon/InCommon-metadata.xml
    > org.apache.http.conn.HttpHostConnectException: Connect to 
md.incommon.org:80 [md.incommon.org/163.253.32.9] failed: Connection refused
    > 10.110.29.20|2017-09-15 03:27:27,382 - WARN 
[org.opensaml.saml.metadata.resolver.impl.FileBackedHTTPMetadataResolver:295] 
- Metadata Resolver FileBackedHTTPMetadataResolver InCommonMD: Problem 
reading metadata from remote source; detected existing cached metadata, 
skipping load of backup file
    > 
    > On 9/21/17, 11:47 AM, 
"
 on behalf of Cantor, Scott" 
<
 on behalf of 
>
 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
    > 
    > 
    > 
    > 
    > 
    > ________________________________
    > 
    > This e-mail message (including any attachments) is for the sole use of
    > the intended recipient(s) and may contain confidential and privileged
    > information. If the reader of this message is not the intended
    > recipient, you are hereby notified that any dissemination, distribution
    > or copying of this message (including any attachments) is strictly
    > prohibited.
    > 
    > If you have received this message in error, please contact
    > the sender by reply e-mail message and destroy all copies of the
    > original message (including attachments).
    >