General guidance for new admin

Cantor, Scott cantor.2 at osu.edu
Mon May 15 09:37:29 EDT 2017


On 5/13/17, 4:14 PM, "users on behalf of Mike Nielsen" <users-bounces at shibboleth.net on behalf of mnielsen894 at gmail.com> wrote:
>
> 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 
> what we want to do. 

No, what I'm saying is this stuff is incredibly complex and you won't find a simple recipe that solves your problems.

> That's not particularly comforting to a poor schlub like me (in the corporate world) who kind of "inherited" this, especially in view
> of my management's apparent expectation is that it's not at all complex.  That's certainly not my reading so far.

It's not complex when you know it, it's very complex when you don't. Like every technology in the world.

> I'm not sure whether any of our corporate partners might support Shibboleth's approach to SAML -- however that may differ
> 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).

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.

> Am I wrong in interpreting your comment to mean that Shibboleth is not really appropriate for corporate use?

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

-- Scott






More information about the users mailing list