<div dir="ltr">Thank you for your thoughtful response, Scott.<br><br>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.<br><br>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?<br><br></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Dec 1, 2016 at 10:24 AM, 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">> Our ultimate goal, however, is to reconfigure all of our apps to always send all<br>
> unauthenticated users to our IdP first, and then have our own IdP make a<br>
> decision (after identifying the customer that the user belongs to) about<br>
> whether to present the user with a login form or further redirect the user to<br>
> his own IdP, which would present the login form.  In the latter case, I guess<br>
> our own IdP would be acting as an SP to the customer's IdP.  The customer's<br>
> IdP would then assert the user back to our own IdP, which would then in turn<br>
> assert the user to original app the user was trying to access.<br>
<br>
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.<br>
<br>
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.<br>
<br>
> Previously I mentioned that I'm still learning how to talk about this stuff.  I'm<br>
> also learning how to reason about this stuff, too, so if I'm looking at it all<br>
> wrong, I won't be offended if correction is offered.<br>
<br>
No, I just needed to understand your use case.<br>
<br>
> I do appreciate your candor about Shibboleth's ease-of-use (or possible lack<br>
> thereof).  I guess in the end that will be a cost/benefit trade-off decision.  For<br>
> now, I'm mostly interested in learning about whether Shibboleth can do the<br>
> job without begin forced into a usage scenario it was never intended to be<br>
> used in.<br>
<br>
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.<br>
<br>
> Assuming it's a good technical fit, my next step would be to find out<br>
> what I can say to decision-makers about why an organization might be glad,<br>
> in the long run, it chose Shibboleth.<br>
<br>
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.<br>
<span class="HOEnZb"><font color="#888888"><br>
-- Scott<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><br>
</font></span></blockquote></div><br></div>