InCommon metadata support

[Tom Scavo <>]

[copying metadata-support]

On Tue, Jun 3, 2014 at 3:38 PM, Praveen Pinto
<>
 wrote:
>
> Made the change to point to InCommon-metadata.xml instead of fallback, and
> the error is below.  Does this mean that I need to upgrade Shibboleth for
> Windows?

I'm not sure...can you tell what version of Shibboleth you're running?

> I don¹t see any other errors that would give me any more
> information.

Scott, is there anything in the log output below that jumps out at you?

Thanks,

Tom

> 2014-06-03 05:02:26 DEBUG XMLTooling.libcurl.InputStream : libcurl trying
> to fetch http://md.incommon.org/InCommon/InCommon-metadata.xml
> 2014-06-03 05:03:26 ERROR XMLTooling.libcurl.InputStream : error while
> fetching http://md.incommon.org/InCommon/InCommon-metadata.xml: (28)
> Operation timed out after 60000 milliseconds with 10024054 out of 10080294
> bytes received
> 2014-06-03 05:03:26 ERROR XMLTooling.ParserPool : fatal error on line
> 138113, column 41, message: internal error in NetAccessor
> 2014-06-03 05:03:26 ERROR OpenSAML.MetadataProvider.XML : error while
> loading configuration from
> (http://md.incommon.org/InCommon/InCommon-metadata.xml): XML error(s)
> during parsing, check log for specifics
> 2014-06-03 05:03:26 WARN OpenSAML.MetadataProvider.XML : using local
> backup of remote resource
> 2014-06-03 05:03:26 INFO OpenSAML.MetadataProvider.XML : loaded XML
> resource (C:/opt/shibboleth-sp/var/run/shibboleth/InCommon-metadata.xml)
>
>
>
> Praveen Pinto
> Sr TechOps Engineer  c512.773.9021
>
>
>
>
>
> On 5/29/14, 11:47 AM, "Tom Scavo" 
> <>
>  wrote:
>
>>On Thu, May 29, 2014 at 12:33 PM, Praveen Pinto
>><>
>> wrote:
>>>
>>> I will point the Windows box to the SHA256 and test..
>>
>>I'll be very interested in hearing what you find out. This is most
>>important.
>>
>>> As far as SAML1.1
>>> goes, is it supported for our installation?  Or do I need to contact the
>>> few customers you listed below and alert them to move to SAML2?
>>
>>Metadata consumption is a separate issue. Test that first so we know
>>where we stand. Depending on how the testing goes, you can upgrade to
>>SAML2 as time permits. It's not required for metadata consumption,
>>however. It's a completely separate issue.
>>
>>> For the
>>> Linux platform, the ones beginning with pa, we have James Madison,
>>> Dartmouth College, Carleton College, and Virginia Tech.
>>
>>James Madison and Dartmouth deploy SAML1-only IdPs while Carleton and
>>Virginia Tech support both SAML1 and SAML2. In any case, you should
>>upgrade ALL of your SPs to SAML1/SAML2, you don't have to wait for the
>>IdPs.
>>
>>Let me know how the testing goes.
>>
>>Tom
>>
>>> On 5/29/14, 10:53 AM, "Tom Scavo" 
>>> <>
>>>  wrote:
>>>
>>>>On Thu, May 29, 2014 at 11:33 AM, Praveen Pinto
>>>><>
>>>> wrote:
>>>>> The majority of the ones consuming the fallback aggregate are running
>>>>>on
>>>>> Windows server 2008.  There are a few running on Windows server 2003.
>>>>
>>>>Okay, so unless you're running an ancient version of Shibboleth on
>>>>Windows, those deployments should be compatible with SHA-256. It's
>>>>easy to test, just point one of them to the production aggregate and
>>>>see what happens. Have you tried that?
>>>>
>>>>> Unrelated topic: I also read a bit about a change in Incommon
>>>>>certificate?
>>>>
>>>>Yes, the certificate wrapper on the public key has changed. The public
>>>>key itself has NOT changed.
>>>>
>>>>>  Do we have to do anything on our end for the change in cert?  It
>>>>>wasn't
>>>>> too clear to me.
>>>>
>>>>It's not strictly required that you upgrade to the new certificate but
>>>>why not? In any case, the SHA-256 issue should be your first priority.
>>>>Once that's resolved, you can migrate to the new certificate as time
>>>>permits.
>>>>
>>>>Tom
>>>>
>>>>> On 5/29/14, 10:22 AM, "Tom Scavo" 
>>>>> <>
>>>>>  wrote:
>>>>>
>>>>>>Hi Praveen,
>>>>>>
>>>>>>Thanks for the update. Let's drill down a little deeper. For the ones
>>>>>>that are consuming the fallback aggregate, what platform are they
>>>>>>running on?
>>>>>>
>>>>>>Thanks,
>>>>>>
>>>>>>Tom
>>>>>>
>>>>>>
>>>>>>On Thu, May 29, 2014 at 11:15 AM, Praveen Pinto
>>>>>><>
>>>>>> wrote:
>>>>>>> Hi Tom,
>>>>>>>
>>>>>>> We have 2 shibboleth SP setups.  One that encompasses everything
>>>>>>>that
>>>>>>> begins with pa.  The other is for everything that begins with emp
>>>>>>> The ones that begin with pa, even though they have a mix of saml1.1
>>>>>>>and
>>>>>>> saml2 are pointing to
>>>>>>> http://md.incommon.org/InCommon/InCommon-metadata.xml for the
>>>>>>>metadata
>>>>>>> provider and using Shibboleth SP Version 2.5.3.
>>>>>>> For the server with the emp URL's, we are downloading once a day
>>>>>>>from
>>>>>>> http://md.incommon.org/InCommon/InCommon-metadata-fallback.xml
>>>>>>> These servers also use an older version of shibboleth for windows,
>>>>>>>which
>>>>>>> we do not believe can handle SHA2 algorithm.
>>>>>>>
>>>>>>> Let me know if I am not making sense on any of this.  I read the
>>>>>>>release
>>>>>>> in detail, and thought the only thing I needed to do was upgrade
>>>>>>> Shibboleth on our windows server to 2.5.3 and point to
>>>>>>> incommon-metadata.xml from the fallback.
>>>>>>>
>>>>>>> Thanks
>>>>>>>
>>>>>>>
>>>>>>> Praveen Pinto
>>>>>>> Sr TechOps Engineer  c512.773.9021
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On 5/28/14, 3:22 PM, "Tom Scavo" 
>>>>>>> <>
>>>>>>>  wrote:
>>>>>>>
>>>>>>>>Hi,
>>>>>>>>
>>>>>>>>Beginning on June 30th, all metadata aggregates published by the
>>>>>>>>InCommon Federation will be signed using the SHA-256 digest
>>>>>>>>algorithm.
>>>>>>>>In light of that milestone event, we have determined that a number
>>>>>>>>of
>>>>>>>>your published SPs are at risk:
>>>>>>>>
>>>>>>>>https://emp037.peopleadmin.com/shibboleth
>>>>>>>>https://emp041.peopleadmin.com/shibboleth
>>>>>>>>https://emp041test.peopleadmin.com/shibboleth
>>>>>>>>https://emp114.peopleadmin.com/shibboleth
>>>>>>>>https://emp193.peopleadmin.com/shibboleth
>>>>>>>>https://emp193test.peopleadmin.com/shibboleth
>>>>>>>>https://emp219.peopleadmin.com/shibboleth
>>>>>>>>https://pa1227.peopleadmin.com/shibboleth
>>>>>>>>https://pa1329.peopleadmin.com/shibboleth
>>>>>>>>https://pa160.peopleadmin.com/shibboleth
>>>>>>>>https://pa953.peopleadmin.com/shibboleth
>>>>>>>>
>>>>>>>>The above are SAML1-only SPs and therefore it is quite possible that
>>>>>>>>these deployments are not compatible with SHA-256.
>>>>>>>>
>>>>>>>>Two questions for you today: Are the above deployments automatically
>>>>>>>>refreshing metadata? [1] If so, are they consuming the production
>>>>>>>>metadata aggregate? [2] In any case, can you get back to me asap and
>>>>>>>>let me know what you find out?
>>>>>>>>
>>>>>>>>Thanks,
>>>>>>>>
>>>>>>>>Tom Scavo
>>>>>>>>Operations Manager
>>>>>>>>InCommon.org
>>>>>>>>
>>>>>>>>[1] https://spaces.internet2.edu/x/JwQjAQ
>>>>>>>>[2] https://spaces.internet2.edu/x/SoG8Ag
>>>>>>>
>>>>>
>>>
>