advocacy tips

[Charlton Rose]

Thank you for your thoughtful response, Scott.

To summarize, I think you are saying that Shibboleth IdP does not currently
have any real support for SAML proxying right now, but it may, some day,
since Shibboleth is committed leading the charge in SAML support.

What's not clear to me, however, is why it would be necessary to add
support to Shibboleth SP for SAML proxying.  I would have expected the
whole notion of SAML proxying to be completely opaque to any SP that is
authenticating through an IdP that happens to be acting as a proxy for
another IdP.  I mean, why should the SP care whether the IdP authenticates
the user on its own or by delegation?


On Thu, Dec 1, 2016 at 10:24 AM, Cantor, Scott <cantor.2 at osu.edu> wrote:

> > 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.
>
> I get it. The Shibboleth IdP does not have any built-in support for that
> kind of proxying. It's just never been our goal in the past or how we
> looked at things, and because our SP wasn't in Java, it was never a simple
> project to add that kind of feature set in without having a much more
> stripped down SP to handle that half. While it's something I think we will
> do, or at least that I would like to do, it isn't the strength of the
> software today. It's pretty cut and dried in that sense.
>
> As a SAML IdP, I think we're best of breed personally, provided a GUI
> isn't your priority. As a proxy, we're not even in that conversation
> pragmatically outside of running the SP in front of our IdP with Apache in
> the middle.
>
> > 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.
>
> No, I just needed to understand your use case.
>
> > 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.
>
> I wouldn't say "never intended" exactly, but never directly supported, no.
> I think the best open source option in that particular space is simpleSAML.
>
> > 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.
>
> Aside from the proxying gap, the strenth of the software is the duty of
> care behind it, the commitment to continue to support SAML as the first
> priority that I think is virtually unique to this project, and lastly the
> flexibility exposed to deployers with enough Java and Spring skills to take
> advantage of it. That's my biased perspective.
>
> -- 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/1d41f2e0/attachment.html>