InCommon Operations Notifications

[Thomas Scavo <>]

You are receiving this message because you are a designated Site 
Administrator for InCommon. If your organization deploys an Identity Provider 
(IdP) in the InCommon Federation, please READ ON. 

First, please review the previous InCommon guidance on protecting against 
failed metadata processes [1] in the face of eduGAIN metadata, which caused 
InCommon metadata to nearly double in size. 

There are two sections below, one for simpleSAMLphp deployers and one for 
deployers of the Shibboleth IdP software. 

simpleSAMLphp -- If you are running simpleSAMLphp, and its metarefresh 
process is running smoothly, then it is unlikely you will encounter issues in 
the near term. In any case, consider upgrading to the recently announced SSP 
1.14.0, which has new metarefresh features.

Shibboleth IdP -- If you are running Shibboleth IdP V2 (earlier than V2.4.5) 
or Shibboleth IdP V3 (earlier than V3.2.0), you should make sure you have 
patched your logging configuration and allocated sufficient heap in the JVM. 
For details, please READ ON.

Shibboleth IdP logging -- If you have NOT patched your logging configuration 
as described in [1], perform the ACTION described at the end of this message 
and then apply the documented logging patch ASAP. Otherwise issues with your 
Shibboleth IdP deployment may develop and will continue undetected until your 
system metadata EXPIRES, at which point all subsequent SAML transactions will 
FAIL.

Shibboleth IdP memory -- Be sure you have allocated sufficient heap in the 
JVM. Simple deployments may get by with 1024MB while more complex deployments 
may require 2048MB or more. Unfortunately, measures of deployment complexity 
remain subjective. To be safe, allocate more than you need.

TIP. For large metadata files, the Shibboleth Project now recommends that 
Shibboleth IdP deployers allocate at least 1500MB of heap space in the JVM. 
Lead developer Scott Cantor candidly advises: “Use a 64-bit OS, hand it 3G or 
more, and stop wasting valuable person time trying to save money on RAM.”

If you have questions or comments, please post them to the 

 mailing list: https://lists.incommon.org/sympa/info/metadata-support 

Tom Scavo
for InCommon Operations

[1] Protect Against Failed Metadata Processes 
https://spaces.internet2.edu/x/zgFwBQ 

BEGIN ACTION.

To check if your metadata refresh process is functioning normally, first 
determine the location of your metadata backing file. For example, the 
following configuration clearly shows the location of the backing file:

<MetadataProvider id="ICMD" xsi:type="FileBackedHTTPMetadataProvider"
     xmlns="urn:mace:shibboleth:2.0:metadata"
     metadataURL="http://md.incommon.org/InCommon/InCommon-metadata.xml";
     backingFile="/opt/shibboleth-idp/metadata/InCommon-metadata.xml">

Now locate the backing file in the file system and inspect the dateTime value 
of the creationInstant XML attribute on the <mdrpi:PublicationInfo> element 
(on approximately line 57 of the file). The value of the creationInstant XML 
attribute will tell you when your system last refreshed metadata. If you find 
an unexpected value, your metadata refresh process may have quietly FAILED 
and your immediate action is REQUIRED. If you do nothing, your IdP will CEASE 
TO OPERATE when the metadata file finally expires. (Note that InCommon 
metadata routinely expires in two weeks.)

END ACTION.