shibboleth-dev - RE: [Shib-Dev] SP development documentation
Subject: Shibboleth Developers
List archive
- From: "Scott Cantor" <>
- To: <>
- Subject: RE: [Shib-Dev] SP development documentation
- Date: Thu, 10 Jun 2010 17:58:23 -0400
- Organization: The Ohio State University
> Then my idea is to create an extension / handler (e.g. like the DS
handler)
> so that the SP is able to receive metadata from the TDS on the fly and of
> course, will use the metadata immediately.
>
> While writing this e-mail I found following describtion in the wiki:
> --------
>
> Dynamic MetadataProvider
Yes, that's basically what you want excepting that it's based on lookups at
URLs that are transforms of an entityID, so you have to get to an entityID
to start with. If you have that starting point, the plugin will do a fetch
with the URL.
The trust mechanisms supported for the transport layer and the caching
behavior have evolved drastically, and the svn branch is changed again from
what was in 2.3. I say this every release, but I'm hoping 2.4 is finally a
usable baseline for it.
The svn code also supports the transform option to dereference a transform
of the entityID rather than just the entityID. So you can request entityID
foo via https://metadataservice.fed.org/lookup?entityID=foo. Etc.
> This already sounds very near to the solution I am looking for. The only
> question is when the action retrieving metadata will be flipped?
Immediately
> after the SP receives an entityID from DS?
It's internal to the metadata lookup process, and that's triggered by any
call to the installed MetadataProvider's lookup method, which happens in
many places in the code. One of them is in the SessionInitiator chain, yes.
> If yes, then I don't need to create any extension more. It would be great!
> I'll try this configuration tomorrow. Wow!
As I say above, the svn branch is vastly changed (again) from what's in 2.3,
and has a number of fixes to caching behavior.
Aside from copying that plugin, it's also possible to subclass just the
DynamicMetadataProvider class in opensaml, by overriding a resolve() method
that does the actual lookup over the network. The cache handling is internal
to the base class.
The actual type="Dynamic" implementation is inside libshibsp, but is a
subclass of the opensaml version that just adds the transport-layer
configuration and trust capablities of the SP in place of a generic HTTP
client fetch.
-- Scott
- SP development documentation, Yang Xiang, 06/10/2010
- RE: [Shib-Dev] SP development documentation, Scott Cantor, 06/10/2010
- Re: [Shib-Dev] SP development documentation, Yang Xiang, 06/10/2010
- RE: [Shib-Dev] SP development documentation, Scott Cantor, 06/10/2010
- Re: [Shib-Dev] SP development documentation, Yang Xiang, 06/10/2010
- RE: [Shib-Dev] SP development documentation, Scott Cantor, 06/10/2010
- RE: [Shib-Dev] SP development documentation, Yang Xiang, 06/11/2010
- Re: [Shib-Dev] SP development documentation, Scott Cantor, 06/11/2010
- Re: [Shib-Dev] SP development documentation, Yang Xiang, 06/13/2010
- RE: [Shib-Dev] SP development documentation, Scott Cantor, 06/14/2010
- RE: [Shib-Dev] SP development documentation, Yang Xiang, 06/11/2010
- RE: [Shib-Dev] SP development documentation, Scott Cantor, 06/10/2010
- Re: [Shib-Dev] SP development documentation, Yang Xiang, 06/10/2010
- RE: [Shib-Dev] SP development documentation, Scott Cantor, 06/10/2010
- Re: [Shib-Dev] SP development documentation, Yang Xiang, 06/10/2010
- RE: [Shib-Dev] SP development documentation, Scott Cantor, 06/10/2010
Archive powered by MHonArc 2.6.16.