Dynamic Configuration of IdP

[M]

Leveraging would be great.  So would we do something like this if we were setting up an IdP for ADFS?

<MetadataProvider
    type="XML"

    uri="https://your-domain.com/FederationMetadata/2007-06/FederationMetadata.xml"

    backingFilePath="federation-metadata.xml"

    reloadInterval="7200"
/>

Yes, we're aware that someday there might be multiple IdPs per organization, and we'll need to provide a different user interface then.  For now though, the vast majority of the organizations will just have one IdP so it didn't make sense to provide those users a choice of IdPs.

We don't have a preference one way or the other about managing via metadata.  The problem we're trying to solve is to minimize or eliminate the need for a developer or sys admin from having to be involved every time a customer organization wants to setup a new IdP.  We've already received multiple requests from clients to interface to their ADFS and Microsoft 365 and other IdPs.  If support could obtain the necessary information and enter it into our web application to use with Shibboleth, that would greatly reduce the time needed by developers and sys admins.  If that means managing the metadata, that is okay.

Thanks for your help.  It's very useful.



------------------------------
On Mon, Sep 30, 2013 9:14 PM EDT Cantor, Scott wrote:

>On 9/30/13 8:26 PM, "M" <mlsaghir at yahoo.com> wrote:
>
>>4. The support organization will fill out an online form to configure the
>>IdP settings for each customer organization.  The settings will be saved
>>to be used by Shibboleth to allow for single sign on.
>
>You should instead leverage a source of trusted metadata from those IdPs
>and not do this manually. That's wasted effort on your part, doesn't solve
>the trust problem (how would your support staff know any of the
>information?) and reduces the chance of maintaining the information
>accurately and dealing with key changes.
>
>Metadata automates all of that, even if the actual metadata exchange has
>to be set up initially without the help of a federation. Manual effort to
>create a safe, ongoing relationship is much better than one-time manual
>work that orphans the information and prevents it from being maintained.
>
>>5. Each organization has its own login URL, so the system will know which
>>IdP to use.  
>
>That works as long as you never plan to expose a single resource to users
>from multiple IdPs. That could be true, but it's also possible that will
>change and then you have a messed up user experience.
>
>>Our main question relates to #4.  From our research, it looks like one
>>way to save the IdP settings is to create a new shibboleth2.xml file each
>>time an IdP is added or updated, but is this the best way?  Our web
>>application is in java, and has a database so are there better ways to
>>save the settings?
>
>The only information in shibboleth2.xml related to IdPs is generally
>hardwiring their entityIDs to bypass discovery, assuming that's even
>necessary. Metadata is where all the IdP information is.
>
>Even if you don't want to manage the information via metadata, you will
>have no choice but to generate it to provision the SP because there is no
>other way to provide it.
>
>-- Scott
>
>
>--
>To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net