IDP Relying Party Reload Behavior

[John Mitchell]

On Sat, Aug 20, 2011 at 3:13 PM, Chad La Joie <lajoie at itumi.biz> wrote:
> On Sat, Aug 20, 2011 at 18:35, John Mitchell <jpmitchell at alaska.edu> wrote:
>>    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?
>
> That config looks okay.  I don't recommend setting the min and max
> delay to the same amount, that just doesn't make any sense.  First, be
> sure you're running the latest version of the IdP.  Then turn on
> debugging for the OpenSAML metadata package to see when exactly things
> will reload and actually perform the reloading.
>

    You are right. It is not a reasonable configuration. It was mostly
for testing. The real issue here is I can see the IdP reload the
relying party config but it never senses that the metadata file
referenced in the relying party configuration has changed. I can not
turn up the debugging on my production IdP, but I will certainly spend
some time with my test IdP and reproduce the problem with debugging
turned on.

>>    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.
>
> Don't use a separate file per relying party, just use one file for all
> manually maintained relying party metadata.  Otherwise you'll need to
> add a new metadata provider for every new service that comes along.
> That would require you to either turn on reloading for
> relying-party.xml (something I do not recommend in a production
> system) or restart the IdP.  Using a single file, with a reloading
> metadata provider, you can just edit the metadata for a given SP
> within the larger collection.
>

    I currently have the relying party configuration setup to reload
automatically every fifteen minutes. I check all config changes on my
identical IdP that is not running production load and then move the
changes through version control to the production IdP. Right now the
multiple file metadata configuration and support process is fairly
well built up and documented so I am sticking with it for the time
being. I know something else will need to be done in the long term and
I am working towards that but I am not there yet.

> --
> Chad La Joie
> www.itumi.biz
> trusted identities, delivered
> --
> 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