General guidance for new admin

[Mike Nielsen]

Tom, thank you so much for your informative reply.

I have been pursuing the Web Browser SSO documentation and it's slowly
starting to sink in.

It's so kind of you to take the time to respond, and I greatly appreciate
your words of wisdom; I shall take them on-board as I try to get us out of
this little jam we're in.

Thanks again.


On Sat, May 13, 2017 at 5:58 PM, Tom Scavo <trscavo at gmail.com> wrote:

> 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
> --
> To unsubscribe from this list send an email to
> users-unsubscribe at shibboleth.net
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/users/attachments/20170513/e84aeffd/attachment-0001.html>