Dynamic Configuration of IdP

[Cantor, Scott]

On 9/30/13 11:08 PM, "M" <mlsaghir at yahoo.com> wrote:
>
>Leveraging would be great.  So would we do something like this if we were
>setting up an IdP for ADFS?

There's nothing supplied there to verify the metadata you're importing.
It's blind trust.

>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.

I'm not necessarily talking about multiple IdPs per org, I'm talking about
multiple orgs per resource. Actual federation as opposed to siloed
resources.

>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.

Short of relying on a federation, you have to do a lot of work.

>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.

It does, but if you're going to do that, you might as well give control
over the information to the customer via a web form. If I can't get an SP
to do the right thing, the worst thing is for them to manually handle it
on my behalf. Better that I can update the information remotely than have
to go through somebody else to do it. At least than I'm in control of the
timing of changes.

>From my perspective of course, I'd be happy for an SP to accept my
self-signed metadata and pull it from me. But that means you have to
manage a key exchange for every customer, which doesn't scale. But if you
care at all about your data, accepting the metadata blindly isn't really a
viable option either. Or if it's my data (I don't know the nature of your
service), then I'm the one who's not happy if you blindly accept my
metadata.

The other point is that you're almost certainly going to get the security
wrong without a lot of experience. Using inline keys creates an absolute
obligation to prevent acceptance of remotely supplied metadata without an
expiration on it. Otherwise it's impossible to guarantee revocation of a
compromised key.

You may find this helpful:

https://wiki.shibboleth.net/confluence/display/SHIB2/TrustManagement

-- Scott