One IDP to Multiple SPs
Paul Hethmon
paul.hethmon at clareitysecurity.com
Wed May 30 15:29:02 BST 2012
Assume you have the following files in your Shibboleth metadata folder:
local-sp.xml
third-party-sp.xml
federation-sp.xml
All of these will be loaded in the relying-party.xml file. Inside each of
those files, you will place metadata for one or more service providers.
Now if you get a new service provider, you add their metadata to one of
those files. Shib will see the timestamp for the file change and reload.
How you actually organize the metadata and files is entirely up to you,
whatever fits your business needs.
Paul
On 5/30/12 10:18 AM, "Kuehner, Angela" <akuehne at ju.edu> wrote:
>Thanks for the information. Unfortunately, I am relatively new to
>Shibboleth and I don't fully understand your reply. I have tried reading
>the Shibboleth wiki but have not found an answer yet.
>
>Is there another way to add a MetaData provider without modifying the
>RelyingParty.XML? When you say Federate with someone else, what exactly
>does that mean?
>
>I apologize in advance for the newbie questions but I am still learning.
>
>Thanks!
>
>-----Original Message-----
>From: users-bounces at shibboleth.net [mailto:users-bounces at shibboleth.net]
>On Behalf Of Cantor, Scott
>Sent: Tuesday, May 29, 2012 4:42 PM
>To: Shib Users
>Subject: Re: One IDP to Multiple SPs
>
>On 5/29/12 4:34 PM, "Kevin P. Foote" <kpfoote at iup.edu> wrote:
>
>>Generally you'd group similar* SPs in a small number of metadata files
>>that your RelyingParty.xml file will then reference / load. Some people
>>combine all to a single file and load that.
>>
>>I personally load 3 metadata files on our IdP (Incommon, LocalSPs,
>>PartnerSPs).
>
>That's loosely speaking my setup, but "local" has become "can be
>scripted/generic" and "partner" has become "pain in neck that has to be
>manually dealt with in some way".
>
>You (meaning the OP) should not be modifying relying-party.xml every time
>you federate with something and I'm not aware of anything in the
>documentation that is supposed to lead to that conclusion.
>
>-- Scott
>
>--
>To unsubscribe from this list send an email to
>users-unsubscribe at shibboleth.net
>--
>To unsubscribe from this list send an email to
>users-unsubscribe at shibboleth.net
More information about the users
mailing list