sp services limit

[Cantor, Scott]

> This is an interesting statement to me, because it means I probably have
> something significant still to learn about Shibboleth. Suppose you have
> one application with a few hundred customers and each sends different
> attributes.  One might release uid for authorization and another might
> send uid to everybody but prefer ePPN for authorization.  A third might
> be unable to get their house in order and only be able to send something
> named mysillyattributename.

Well, generally speaking, that's a mess, there's no question about it.

> Once you go down the road to this extent, it
> is much simpler administratively to have a separate attribute map for
> each customer.  (Besides which it allows the SP to avoid the need for
> discovery.)

You don't need overrides for discovery, there are much simpler ways to deal with that, as long as you have appropriate authorization in place. Unless you're going to segregate metadata so that only one IdP's metadata is present in every override, the discovery issue is something you can address with just a simple content setting per vhost. And the federation in model in Shibboleth is definitely not designed for the one-IdP-per-override metadata approach, at least not with the large aggregates we have now.

The attribute map issue is a problematic one, I can't deny that, but I think it's a much cleaner solution to push for standardization of attributes and handle the one-offs in code if it's really needed.

>  Are you saying it is bad form to create a separate
> application ID for each of these integrations?  Is there a better way to
> accomplish this?

I think it's a bad idea in general, yes. I know of some SPs that do it, but it is best avoided. I think it's a sign of trying to get the SP to do a certain amount of work that, because of the use case, is just not easily delegated to it. That happens.

-- Scott