Shibboleth Developers

[Chad La Joie <>]

In case people want to track this:

Signing tool:
https://bugs.internet2.edu/jira/browse/JXT-25

IdP Metadata Tool:
https://bugs.internet2.edu/jira/browse/SIDP-24

Chad La Joie wrote:
> Yes, the same is true for the metadatatool on the Java side.  Rod and I 
> have discussed this a couple time and my current thinking is as follows.
>
> Current metadata tool basically does three things.  Pulls metadata, 
> signs metadata, and validates the signature of the file.  The new code, 
> as Scott mentions, provide metadata tooling that is capable of doing all 
> of this in process.
>
> So, my thinking is that I'll dump the metadata tool as it currently 
> exists and replace it with a generic signature tool that can be used to 
> sign and verify various types of XML files.  Then, in a bit of time once 
> all our config files settle down with the IdP, create a new IdP metadata 
> tool that will, at least, generate valid metadata EntityDescriptor 
> elements from the IdP's config files.
>
> Note that none of these command line tools will be expected to be used 
> with a cron job to pull files down.  As Scott noted, every platform 
> already has some way of doing that in a robust way to achieve this.
>
> Scott Cantor wrote:
> > There have been a couple of bugs reported against the siterefresh tool 
> > from
> > alpha testers, which isn't surprising since I haven't touched it yet, 
> > and it
> > wasn't actually part of the "supported" alpha release.
> >
> > In response, I've alluded to the fact that I really haven't decided 
> > yet what
> > to do about the tool, but am leaning toward rethinking its purpose. 
> > You can
> > see a bit of that here:
> >
> > https://bugs.internet2.edu/jira/browse/SSPCPP-30
> >
> > I think the same arguments, perhaps less so, apply to the Java version,
> > apart from its function as a file signing utility, something we really
> > needed to genericize anyway (I mean, requiring keystores just to sign 
> > a file
> > is really hideous).
> >
> > So in a nutshell, I'll listen to arguments, but my inclination is to dump
> > siterefresh and replace it with something that is essentially a wrapper
> > around the metadata plugins and filters in Shib 2.0 to allow for somebody
> > that needed to test or verify a metadata file out of band before 
> > supplying
> > it to an SP.
> >
> > The justification for this is that for standard cases, most 2.0 deployers
> > should be able to turn off their siterefresh scripts and just use the
> > built-in code that fetches and caches a remote file periodically. I have
> > backported some code from Xerces 3.0 as part of my 2.7.1 package so 
> > that it
> > can load files from https:// servers, something it can't do currently.
> >
> > My general outlook is that it's a mistake to try and reinvent curl (or 
> > wget)
> > and that the proper approach is to use those tools to feed stdin if we 
> > keep
> > a tool similar to siterefresh in the picture. As I have done in the past,
> > the Windows SP will always include a curl.exe for that purpose.
> >
> > -- Scott

--
Chad La Joie             2052-C Harris Bldg
OIS-Middleware           202.687.0124