IDP Relying Party Reload Behavior

John Mitchell jpmitchell at alaska.edu
Sat Aug 20 23:35:26 BST 2011


Scott,

On Fri, Aug 19, 2011 at 11:51 AM, Cantor, Scott <cantor.2 at osu.edu> wrote:
> On 8/19/11 3:03 PM, "John Mitchell" <jpmitchell at alaska.edu> wrote:
>>
>>    What do you mean by tell it to?
>
> Follow the documentation and shrink the reload intervals if you want them
> lower than the default. There is no "reload if changed" option. It won't
> stat the file, it polls in the background looking for changes so it won't
> ever guarantee a reload the instant it changes.
>

    Gotcha. I think I tried that to no avail with the
min/maxRefreshDelay attribute. It still had the old metadata in memory
after it auto reloaded the config and I waited an hour. The config
looks like this in the relying party configuration:

        <MetadataProvider id="knowledge-test.alaska.edu"
xsi:type="ResourceBackedMetadataProvider"
            minRefreshDelay="PT15M" maxRefreshDelay="PT15M"
            xmlns="urn:mace:shibboleth:2.0:metadata">
            <MetadataResource xsi:type="resource:FilesystemResource"

file="/opt/shibboleth-idp/metadata/knowledge-test-metadata.xml" />
        </MetadataProvider>

Am I doing something wrong?

>>I think my brute force approach of changing the relying party
>>config is not causing the the metadata to be reloaded. The logs show
>>the relying party configuration reloads but the already loaded
>>metadata for the SP does not appear to reload even though the file on
>>disk has changed. Does that make sense?
>
> Not really, no.

    Sorry about that. I will try again by backing up some and
explaining my purpose behind what I am trying to do. I manage UA
metadata basically by hand with a simple point to point trust model.
This is due to the fact that at present I am leveraging Shib to
replace a home grown trusted third party protocol implementation and
to get my users into federated resources. So, I just store the
metadata for each UA SP in a separate file and chain them all together
in the relying party configuration. I know this will not scale at some
point and I am already thinking about how to better manage it but I am
not there yet. What I wish to be able to do is add metadata the same
way via local files without interrupting the production IdP, but have
the ability to change metadata files for SPs, should they need it,
without restarting the production IdP. This is what is not working
right now. For example: I add some metadata for SP "A" via a file.
Everything works fine after the relying party config auto reloads.
Then the admin for SP "A" decides to change something and gives me new
metadata for SP "A". I replace the file on the filesystem that
contains the metadata for SP "A" and the metadata never reloads. The
old metadata is continued to be used until I restart which is becoming
harder and harder to do as adopting of the service goes up. Is this
normal behavior or am I doing something wrong? Thanks for your help
and patience with my explanation and attempts to articulate myself.

>
> -- Scott
>
> --
> To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net
>



-- 
John P. Mitchell <jpmitchell at alaska.edu>
907.450.8320
http://www.alaska.edu/oit/iam

"All mankind is divided into three classes: those that are immovable,
those that are movable, and those that move." - Benjamin Franklin


More information about the users mailing list