<div dir="ltr">Tom, thank you so much for your informative reply.<div><br></div><div>I have been pursuing the Web Browser SSO documentation and it's slowly starting to sink in.</div><div><br></div><div>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.</div><div><br></div><div>Thanks again.</div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Sat, May 13, 2017 at 5:58 PM, Tom Scavo <span dir="ltr"><<a href="mailto:trscavo@gmail.com" target="_blank">trscavo@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Fri, May 12, 2017 at 12:38 PM, Mike Nielsen <<a href="mailto:mnielsen894@gmail.com">mnielsen894@gmail.com</a>> wrote:<br>
><br>
> Now, we would like to entertain several more use-cases:<br>
><br>
> Users within the domain of a licensed client would like to have SSO<br>
> capability -- authenticating to their web portal one time only, then having<br>
> access to our SaaS without the need to again provide credentials;<br>
<br>
</span>That is precisely SAML Web Browser SSO. To incorporate that use case,<br>
you don't need to do anything different from what you're doing right<br>
now (except perhaps freshen your Shibboleth SP software version).<br>
<span class=""><br>
> Some clients would like to be able to provide a user id/password to our<br>
> login page, but have the user id's and passwords be from *their*<br>
> authentication domains (i.e. corporate AD or whatever).<br>
<br>
</span>Those clients are not a good fit for *any* SAML SP deployment<br>
(Shibboleth or otherwise). That's not how federated login works.<br>
<br>
The problem is partly of your own making. If you are still exposing a<br>
login page in your app, you are doing it wrong. You want to distribute<br>
the login page away from your application. That's what a SAML IdP<br>
does.<br>
<br>
But you are an SP, not an IdP. You may choose to deploy an IdP to<br>
handle legacy user accounts, but that is all. I presume you are not in<br>
the business of handing out user accounts to clients. If clients want<br>
access to your app, they need to deploy their own IdP.<br>
<span class=""><br>
> The list of clients doing this is fairly small.<br>
<br>
</span>One is too many, I'm afraid.<br>
<span class=""><br>
> Overall, we expect to have only a few distinct IdP's (<25).<br>
<br>
</span>This is where it gets interesting. How are you going to manage<br>
metadata for 25 IdPs? (more on this below)<br>
<span class=""><br>
> We use the user's email address as their user name<br>
<br>
</span>Let me read between the lines (well, one line :) For historical<br>
reasons, your app uses email address as a user identifier. That worked<br>
fine as long as there was only one IdP but you will quickly find that<br>
email address makes a poor user identifier.<br>
<span class=""><br>
> and that can identify<br>
> the IdP for the user (after inspection: i.e. via the email domain)<br>
<br>
</span>No, it can't. An SP that operates on that assumption is a sitting<br>
duck. Suppose <a href="mailto:user@domain1.com">user@domain1.com</a> is a bona fide user at IdP1 with<br>
entityID <a href="https://domain1.com/idp" rel="noreferrer" target="_blank">https://domain1.com/idp</a>. Now suppose evil IdP2 with entityID<br>
<a href="https://domain2.com/idp" rel="noreferrer" target="_blank">https://domain2.com/idp</a> asserts email address <a href="mailto:user@domain1.com">user@domain1.com</a><br>
(there's nothing stopping it from doing so). Do you see the problem?<br>
It should be clear that your SP can not key off email address alone.<br>
It would be better to retool your app to require a real user<br>
identifier, with clearly defined scope semantics.<br>
<span class=""><br>
> for<br>
> client privacy reasons we are unable to ask the user to select their<br>
> identity provider from a list.<br>
<br>
</span>Right, this is where the typical corporate use case diverges from the<br>
true federated use case (and it has nothing to do with Shibboleth). If<br>
you can't (or won't) present a list of all possible IdPs to the user,<br>
another possibility is to expose 25 AssertionConsumerService<br>
endpoints, one for each IdP. Lots of SPs adopt this (suboptimal)<br>
strategy.<br>
<br>
After all that, the most interesting question remains...what about<br>
metadata? You have to share your SP metadata with 25 IdPs, and you<br>
have to consume the IdP metadata of those same 25 IdPs. How do you do<br>
that securely, and in such a way as to permit updates to metadata in<br>
both directions? Sorry, there's no silver bullet here.<br>
<br>
Higher ed solves this problem by introducing a trusted 3rd party, the<br>
federation operator, whose job is to aggregate and distribute metadata<br>
to IdP and SP deployments. This is called multilateral federation,<br>
that is, federation at scale. Shibboleth enables multilateral<br>
federation but that's as far as it goes. No software gives you that<br>
out of the box.<br>
<span class="HOEnZb"><font color="#888888"><br>
Tom<br>
</font></span><div class="HOEnZb"><div class="h5">--<br>
To unsubscribe from this list send an email to <a href="mailto:users-unsubscribe@shibboleth.net">users-unsubscribe@shibboleth.<wbr>net</a><br>
</div></div></blockquote></div><br></div>