IdP metadata config docs

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

IdP metadata config docs

Tom Scavo
We've overhauled the IdP MetadataConfiguration [1] wiki page and most
of its child pages. New child pages have been added as well. In
particular, if you're new to the Shibboleth IdP, the (new)
MetadataManagementBestPractices [2] child page will be of interest.

For long-time users, I have a couple of questions:

1. Is anyone using (or has anyone ever used)
ResourceBackedMetadataProvider? If so, can you briefly describe your
use case? (There isn't much in the archives about this esoteric
metadata provider.)

2. Is anyone pulling metadata from a git server (such as GitHub)? If
so, can you briefly describe your use case?

Your answers to these questions will help me write better documentation.

Thanks,

Tom

[1] MetadataConfiguration https://wiki.shibboleth.net/confluence/x/8YAOAQ
[2] MetadataManagementBestPractices
https://wiki.shibboleth.net/confluence/x/JQXKAg
[3] ResourceBackedMetadataProvider
https://wiki.shibboleth.net/confluence/x/CAMnAQ
--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

RE: IdP metadata config docs

Cantor, Scott E.
> 1. Is anyone using (or has anyone ever used)
> ResourceBackedMetadataProvider? If so, can you briefly describe your use
> case? (There isn't much in the archives about this esoteric metadata provider.)

There were back and forth releases early on that switched from FileBacked to ResourceBacked for reasons I don't really have any history on, but there was a point where we finally just decided to stop doing that. Most people using it are doing it for one of two reasons:

- our defaults used it, or they found some example using it and copied it
- subversion-based metadata

The former use case is officially deprecated (use FileBackedHTTP) and the latter is being deprecated in that particular form because we can't really ship the svn libraries due to licensing and svn is dying anyway so it's not worth maintaining. People can continue to supply their own Resource types for custom use cases if needed, and you can use a new one we built that can actually call out to a script. It's the easy way to implement e.g. a database-backed source. So it's mostly an extension point that handles all the metadata lifting and just relies on a plugin to get the stream.

-- Scott

--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: IdP metadata config docs

Greg Haverkamp
In reply to this post by Tom Scavo


On Mon, Jun 11, 2018 at 7:53 AM Tom Scavo <[hidden email]> wrote:

2. Is anyone pulling metadata from a git server (such as GitHub)? If
so, can you briefly describe your use case?

We do.

I guess the use case seems obvious to me, so hopefully I’m not being too pedantic.  We keep the metadata in a git repository hosted on Bitbucket.  This allows us to hunt down errors, as well as to distribute updates easily.  Our IdP’s do a pull from their remotes every 15 minutes.  So, we can edit in our local repo, xmllint the metadata file, commit, and push.  Then we tell folks their service will be ready within 20 minutes.  (Up to 15 for the next pull, up to 5 for the IdP to refresh.)

An unintended plus is that it gives us a web XML editor for simple edits, like adding ACS endpoints and the like.

Greg



Your answers to these questions will help me write better documentation.

Thanks,

Tom

[1] MetadataConfiguration https://wiki.shibboleth.net/confluence/x/8YAOAQ
[2] MetadataManagementBestPractices
https://wiki.shibboleth.net/confluence/x/JQXKAg
[3] ResourceBackedMetadataProvider
https://wiki.shibboleth.net/confluence/x/CAMnAQ
--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]

--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: IdP metadata config docs

Tom Scavo
On Mon, Jun 11, 2018 at 11:18 AM, Greg Haverkamp <[hidden email]> wrote:

>
> On Mon, Jun 11, 2018 at 7:53 AM Tom Scavo <[hidden email]> wrote:
>>
>> 2. Is anyone pulling metadata from a git server (such as GitHub)? If
>> so, can you briefly describe your use case?
>
> We do.
>
> I guess the use case seems obvious to me, so hopefully I’m not being too
> pedantic.  We keep the metadata in a git repository hosted on Bitbucket.
> This allows us to hunt down errors, as well as to distribute updates easily.
> Our IdP’s do a pull from their remotes every 15 minutes.

I don't know much about Bitbucket. Can you provide a metadata
configuration snippet or at least a brief description of the config
you're using?

> So, we can edit in
> our local repo, xmllint the metadata file, commit, and push.  Then we tell
> folks their service will be ready within 20 minutes.  (Up to 15 for the next
> pull, up to 5 for the IdP to refresh.)

Thanks Greg. This is very helpful.

Tom
--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: IdP metadata config docs

Peter Schober
In reply to this post by Greg Haverkamp
* Greg Haverkamp <[hidden email]> [2018-06-11 17:18]:

> On Mon, Jun 11, 2018 at 7:53 AM Tom Scavo <[hidden email]> wrote:
>
> >
> > 2. Is anyone pulling metadata from a git server (such as GitHub)? If
> > so, can you briefly describe your use case?
>
>
> We do.
>
> I guess the use case seems obvious to me, so hopefully I’m not being too
> pedantic.  We keep the metadata in a git repository hosted on Bitbucket.
> This allows us to hunt down errors, as well as to distribute updates
> easily.  Our IdP’s do a pull from their remotes every 15 minutes.

I think Tom meant "pulling metadata from a git server" literally,
i.e., pointing the IDP to something that's not a local file.

The fact that those local files are part of a local git checkout that
also has remotes is immaterial to Tom's question, AFAIU.

-peter
--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

RE: IdP metadata config docs

Rod Widdowson
> The fact that those local files are part of a local git checkout that
> also has remotes is immaterial to Tom's question, AFAIU.

Well, without putting words into anyone's mouth.  The question about resources made me automatically think of the RunnableFileSystemResource[1], which can be told to do things like "git pull" before doing the refresh.

But for me, I'd prefer to have the "git pull" in a cron job and do the wiring with a LocalDynamicMetadataProvider..

By the way Bitbucket is just another "remote git repositories for rent" thing.  Atlassian's I think.

[1] https://wiki.shibboleth.net/confluence/display/IDP30/RunnableFileSystemResource

--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: IdP metadata config docs

Greg Haverkamp
In reply to this post by Peter Schober
On Mon, Jun 11, 2018 at 8:41 AM, Peter Schober <[hidden email]> wrote:
I think Tom meant "pulling metadata from a git server" literally,
i.e., pointing the IDP to something that's not a local file.

Well, I wondered.
 
The fact that those local files are part of a local git checkout that
also has remotes is immaterial to Tom's question, AFAIU.

Yes.  Hence, my quizzical response.  :)

Greg
 

-peter
--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]


--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]