A User Story about an InCommon Sponsored Partner
This is a true story about the trials and tribulations of a Sponsored Partner in the InCommon Federation (who will remain nameless).
- Vendor V is an InCommon Sponsored Partner in good standing.
- Some of V’s partner IdPs are InCommon participants and some are not.
- On Dec 5, 2013, V introduced a new certificate into SP metadata since the existing certificate was set to expire on Dec 15, 2013.
- V is following the SP certificate migration strategy documented in the wiki, that is, only one encryption certificate will be in metadata at any given time (which is a requirement of AD FS, btw).
- On Dec 16, 2013, V reported that three non-InCommon IdP partner deployments stopped working.
- The three deployments that failed are running AD FS. V itself is running simpleSAMLphp (SSP).
- Given what we know about AD FS, we can conclude that the three AD FS IdPs failed because there was an expired certificate in V’s metadata.
- Besides InCommon, V has IdP partners in two regional federations: the NC Federation and the Texas Federation.
- Some of V’s IdP partners (such as the three AD FS IdPs mentioned above) belong to no federation.
Problem: How does V share metadata with all of its partners so as to eliminate potential interoperability issues?