General guidance for new admin

[Tom Scavo]

On Fri, May 12, 2017 at 12:38 PM, Mike Nielsen <mnielsen894 at gmail.com> wrote:
>
> Now, we would like to entertain several more use-cases:
>
> Users within the domain of a licensed client would like to have SSO
> capability -- authenticating to their web portal one time only, then having
> access to our SaaS without the need to again provide credentials;

That is precisely SAML Web Browser SSO. To incorporate that use case,
you don't need to do anything different from what you're doing right
now (except perhaps freshen your Shibboleth SP software version).

> Some clients would like to be able to provide a user id/password to our
> login page, but have the user id's and passwords be from *their*
> authentication domains (i.e. corporate AD or whatever).

Those clients are not a good fit for *any* SAML SP deployment
(Shibboleth or otherwise). That's not how federated login works.

The problem is partly of your own making. If you are still exposing a
login page in your app, you are doing it wrong. You want to distribute
the login page away from your application. That's what a SAML IdP
does.

But you are an SP, not an IdP. You may choose to deploy an IdP to
handle legacy user accounts, but that is all. I presume you are not in
the business of handing out user accounts to clients. If clients want
access to your app, they need to deploy their own IdP.

> The list of clients doing this is fairly small.

One is too many, I'm afraid.

> Overall, we expect to have only a few distinct IdP's (<25).

This is where it gets interesting. How are you going to manage
metadata for 25 IdPs? (more on this below)

> We use the user's email address as their user name

Let me read between the lines (well, one line :) For historical
reasons, your app uses email address as a user identifier. That worked
fine as long as there was only one IdP but you will quickly find that
email address makes a poor user identifier.

> and that can identify
> the IdP for the user (after inspection: i.e. via the email domain)

No, it can't. An SP that operates on that assumption is a sitting
duck. Suppose user at domain1.com is a bona fide user at IdP1 with
entityID https://domain1.com/idp. Now suppose evil IdP2 with entityID
https://domain2.com/idp asserts email address user at domain1.com
(there's nothing stopping it from doing so). Do you see the problem?
It should be clear that your SP can not key off email address alone.
It would be better to retool your app to require a real user
identifier, with clearly defined scope semantics.

> for
> client privacy reasons we are unable to ask the user to select their
> identity provider from a list.

Right, this is where the typical corporate use case diverges from the
true federated use case (and it has nothing to do with Shibboleth). If
you can't (or won't) present a list of all possible IdPs to the user,
another possibility is to expose 25 AssertionConsumerService
endpoints, one for each IdP. Lots of SPs adopt this (suboptimal)
strategy.

After all that, the most interesting question remains...what about
metadata? You have to share your SP metadata with 25 IdPs, and you
have to consume the IdP metadata of those same 25 IdPs. How do you do
that securely, and in such a way as to permit updates to metadata in
both directions? Sorry, there's no silver bullet here.

Higher ed solves this problem by introducing a trusted 3rd party, the
federation operator, whose job is to aggregate and distribute metadata
to IdP and SP deployments. This is called multilateral federation,
that is, federation at scale. Shibboleth enables multilateral
federation but that's as far as it goes. No software gives you that
out of the box.

Tom