IDP Relying Party Reload Behavior

[Tom Poage]

I was using it in the context of a (local) 'static' resource that
reloads (in a ~timely way) when contents are modified.

Guess I incorrectly inferred that "sp metadata is changed" applied to a
local file. For a file-backed _remote_ resource, I'd use what
Scott/Kevin recommeded. Guess my mixup is that one can specify either a
filesystem-based, local ResourceBackedMetadataProvider (cf. example in
the installed relying-party.xml), as well as a (somewhat more
directly-specified) FilesystemMetadataProvider. I.e.

<metadata:MetadataProvider id="IdPMD"
      xsi:type="metadata:ResourceBackedMetadataProvider">
   <metadata:MetadataResource
      xsi:type="resource:FilesystemResource"
      file="/path/shibboleth-idp/metadata/idp-metadata.xml"/>
</metadata:MetadataProvider>

vs.

<metadata:MetadataProvider id="FooMD"
      xsi:type="metadata:FilesystemMetadataProvider"
      metadataFile="/path/shibboleth-idp/metadata/Foo-metadata.xml"/>

I didn't think cacheDuration in a metadata file was deprecated, but that
it is in MetadataProvider.

Tom.

On 08/19/2011 12:07 PM, John Mitchell wrote:
> On Fri, Aug 19, 2011 at 10:00 AM, Tom Poage <tfpoage at ucdavis.edu> wrote:
>>
>> On 08/19/2011 10:50 AM, John Mitchell wrote:
>>> 3. SP metadata file is changed.
>>> 4. IdP never reloads the new SPs metadata and a restart is required.
>>
>> Might try adding cacheDuration to the metadata file itself:
>>
>> <EntitiesDescriptor xmlns="urn:oasis:names:tc:SAML:2.0:metadata"
>>                    ...
>>                    cacheDuration="PT15M">
>>
> 
>     Does the cacheDuration attribute apply to the
> ResourceBackedMetadataProvider? Also the documentation refers to this
> attribute as deprecated. Seems like a solution waiting to become a
> problem.
> 
>> Tom.
>> --
>> To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net