<div dir="ltr"><div>Thanks, Scott.  Sorry about the ambiguity; I'm still learning how to talk about this stuff.<br><br>To answer your questions (or attempt to anyway):<br><br>We offer multiple SaaS products to our customers.  When a user visits one of our apps without a session, we want to redirect them to a separate login service (presumably by POSTing an <span style="font-family:monospace,monospace">AuthnRequest</span>), get them authenticated there, and then have them redirected back to the original SP with a SAML response asserting the user.  From there, the user can begin using the app (SP), or any of our other apps, without having to sign in again (for a while, anyway).<br><br></div>Our apps are already SAML-ready, so our main concern is not integrating SAML into our apps, but rather, building or purchasing the IdP that we're going to connect those apps to.  This is why we're evaluating various SSO solution providers, and why I'm taking a look at Shibboleth.<br><div><br></div><div><div>Some of our customers already have their own SSO providers; our apps currently redirect them back to their own IdPs and wait for the users to 
return with an assertion before letting them in.  For other users, our apps manage their credentials locally and authenticate them using old-school methods, right in the app.<br><br></div><div>Our ultimate goal, however, is to reconfigure all of our apps to <i>always</i> send <i>all</i> unauthenticated users to <i>our</i> IdP first, and then have our own IdP make a decision (after identifying the customer that the user belongs to) about whether to present the user with a login form or further redirect the user to his own IdP, which would present the login form.  In the latter case, I guess our own IdP would be acting as an SP to the customer's IdP.  The customer's IdP would then assert the user back to our own IdP, which would then in turn assert the user to original app the user was trying to access.<br><br></div><div>Previously I mentioned that I'm still learning how to talk about this stuff.  I'm also learning how to <i>reason</i> about this stuff, too, so if I'm looking at it all wrong, I won't be offended if correction is offered.<br></div><div><br></div>I do appreciate your candor about Shibboleth's ease-of-use (or possible lack thereof).  I guess in the end that will be a cost/benefit trade-off decision.  For now, I'm mostly interested in learning about whether Shibboleth can do the job without begin forced into a usage scenario it was never intended to be used in.  Assuming it's a good technical fit, my next step would be to find out what I can say to decision-makers about why an organization might be glad, in the long run, it chose Shibboleth.<br></div><div></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Nov 30, 2016 at 5:19 PM, Cantor, Scott <span dir="ltr"><<a href="mailto:cantor.2@osu.edu" target="_blank">cantor.2@osu.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 11/30/16, 7:02 PM, "users on behalf of Charlton Rose" <<a href="mailto:users-bounces@shibboleth.net">users-bounces@shibboleth.net</a> on behalf of <a href="mailto:charltonrose@workfront.com">charltonrose@workfront.com</a>> wrote:<br>
<br>
> My company has several multi-tenant SaaS products and is looking for a good, customer-facing SSO solution.<br>
> At present, we're expending a lot of energy examining IDaaS providers (OneLogin, Ping, etc.) – some of them<br>
> quite costly – and I've been trying to generate some interest in Shibboleth.  However, I'm dealing with some<br>
> "perception" problems that I'd like some help getting through.  The primary perception problem is that because<br>
> it's free to use, it's not going to be as capable, robust, flexible, or as easy to use as something we can pay for.<br>
<br>
Are you talking IdP or SP? I would assume you mean SP if you're a SaaS provider.<br>
<br>
The SP is really a function of integration strategy. It approaches SAML in general in a way that is hostile by design to the multi-tenant model (because that model is not really federation), but moreover it really is about integrating without integrating. Its design is focused on enterprise SSO and how to do that without embedding a specific technology into the application. That doesn't always, or really even usually, apply to commercial integrations into a platform. It's often not the right solution, but unfortunately most of the other RP software is so badly done that you give up key SAML features to use them.<br>
<br>
> Yes, I know, it's a typical problem one runs into when trying to sell open source to a non-technical decision<br>
> maker.  I'm not asking for those kinds of general arguments, but rather, arguments about IDP/SSO<br>
> implementation.<br>
<br>
If you mean the IdP and not the SP, I'm not sure I understand that being a "customer facing SSO solution" in the sense of a vendor with SaaS products. It may help me to understand the use case more.<br>
<br>
Also, as a general statement, Shibboleth (IdP or SP) is *not* as easy to use as most other options, and nobody involved with the project claims that. It's not trying to be, and it couldn't support what it does while serving that goal. It could be made easier for a subset of use cases (on the IdP side) with additional resources we don't have at present, or a decision to spend what we do have on that problem almost exclusively.<br>
<span class="HOEnZb"><font color="#888888"><br>
-- Scott<br>
<br>
<br>
--<br>
To unsubscribe from this list send an email to <a href="mailto:users-unsubscribe@shibboleth.net">users-unsubscribe@shibboleth.<wbr>net</a></font></span></blockquote></div><br></div>