advocacy tips

[Charlton Rose]

Thanks, Scott.  Sorry about the ambiguity; I'm still learning how to talk
about this stuff.

To answer your questions (or attempt to anyway):

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 AuthnRequest), 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).

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.

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.

Our ultimate goal, however, is to reconfigure all of our apps to *always*
send *all* unauthenticated users to *our* 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.

Previously I mentioned that I'm still learning how to talk about this
stuff.  I'm also learning how to *reason* about this stuff, too, so if I'm
looking at it all wrong, I won't be offended if correction is offered.

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.


On Wed, Nov 30, 2016 at 5:19 PM, Cantor, Scott <cantor.2 at osu.edu> wrote:

> On 11/30/16, 7:02 PM, "users on behalf of Charlton Rose" <
> users-bounces at shibboleth.net on behalf of charltonrose at workfront.com>
> wrote:
>
> > My company has several multi-tenant SaaS products and is looking for a
> good, customer-facing SSO solution.
> > At present, we're expending a lot of energy examining IDaaS providers
> (OneLogin, Ping, etc.) – some of them
> > quite costly – and I've been trying to generate some interest in
> Shibboleth.  However, I'm dealing with some
> > "perception" problems that I'd like some help getting through.  The
> primary perception problem is that because
> > 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.
>
> Are you talking IdP or SP? I would assume you mean SP if you're a SaaS
> provider.
>
> 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.
>
> > Yes, I know, it's a typical problem one runs into when trying to sell
> open source to a non-technical decision
> > maker.  I'm not asking for those kinds of general arguments, but rather,
> arguments about IDP/SSO
> > implementation.
>
> 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.
>
> 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.
>
> -- Scott
>
>
> --
> 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/20161201/67c50b93/attachment.html>