Dynamic Configuration of IdP

[Cantor, Scott]

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