<div dir="ltr">Thank you, Scott for taking the time to help.<div><br></div><div>I appreciate your kind direction.</div><div><br></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, May 15, 2017 at 9:37 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"><span class="">On 5/13/17, 4:14 PM, "users on behalf of Mike Nielsen" <<a href="mailto:users-bounces@shibboleth.net">users-bounces@shibboleth.net</a> on behalf of <a href="mailto:mnielsen894@gmail.com">mnielsen894@gmail.com</a>> wrote:<br>
><br>
> I'm starting to get the impression that we're putting a square peg into a round hole -- Shibboleth may not be the right tool for<br>
> what we want to do.<br>
<br>
</span>No, what I'm saying is this stuff is incredibly complex and you won't find a simple recipe that solves your problems.<br>
<span class=""><br>
> That's not particularly comforting to a poor schlub like me (in the corporate world) who kind of "inherited" this, especially in view<br>
> of my management's apparent expectation is that it's not at all complex. That's certainly not my reading so far.<br>
<br>
</span>It's not complex when you know it, it's very complex when you don't. Like every technology in the world.<br>
<span class=""><br>
> I'm not sure whether any of our corporate partners might support Shibboleth's approach to SAML -- however that may differ<br>
> from any other approach (I'm not saying it doesn't differ, but I'm new to all this, and so don't really know).<br>
<br>
</span>I'm not talking about differences that impact whether things work or impact compatibility, I'm talking about the approach to solving problems and to some degree about the design decisions that the SP is based on, not all of which are well suited to what vendors do in siloing their systems and not truly federating them. Shibboleth is designed to make it possibly to handle many IdPs, whereas you want to handle a small number of them, each likely locked down to a specific instance of your application.<br>
<span class=""><br>
> Am I wrong in interpreting your comment to mean that Shibboleth is not really appropriate for corporate use?<br>
<br>
</span>No, I'm really saying the typical corporate approach to SAML is flawed, has poor security and operational characteristics, and tends to exhibit a range of IAM mistakes, one of which you mentioned (using email addresses as identifiers).<br>
<div class="HOEnZb"><div class="h5"><br>
-- Scott<br>
<br>
<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><br>
</div></div></blockquote></div><br></div>