General guidance for new admin

[Mike Nielsen]

Many thanks, Scott, for your kind and helpful reply.  I do greatly
appreciate your taking the time and effort to help out.

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.
In particular, you remark:

*There is no book on Shibboleth. There are probably books on SAML, but I
wouldn't know what they are or how relevant they would be to using
Shibboleth, which approaches SAML very differently from the corporate
world.*


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

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

Thanks again for your kindness in taking the time to reply.

On Sat, May 13, 2017 at 2:05 PM, Cantor, Scott <cantor.2 at osu.edu> wrote:

> On 5/12/17, 12:38 PM, "users on behalf of Mike Nielsen" <
> users-bounces at shibboleth.net on behalf of mnielsen894 at gmail.com> wrote:
>
> > Having had no previous experience with it, I would be grateful if some
> kind soul could provide me with some high-level guidance.
>
> I doubt you'll find anything I say "high level" but I can only go so high,
> so you'll need somebody else to help if that's the case.
>
> > 1. Users within the domain of a licensed client would like to have SSO
> capability -- authenticating to their web portal one time
> > only, then having access to our SaaS without the need to again provide
> credentials;
>
> SAML handles federated authentication between your customers' IdP(s) and
> your system via the SP software. They get prompted if/when the IdP decides
> they need to be, that's not under your control in general unless you need
> it to be.
>
> You're already doing this. The SP doesn't know or care that your current
> IdP is "internal". The process within it doesn't change whether you have 1
> IdP or 1000, that's what's different about Shibboleth vs. ADFS or other
> options. You give it metadata for all the IdPs, you make sure you have a
> sound attribute-based strategy for identifying people, etc, and you're
> largely there.
>
> But there are a multitude of tremendously deep and complex issues embedded
> in the application side of this, and that's not something I can just thrown
> into an email. Once you take on federated identity, that is a "big deal",
> and no software can make it less of one.
>
> If you understand SAML, IAM concepts, federated identity, using attributes
> and identifiers safely (e.g., your email address comment strongly implies a
> concern there), then the SP is really just a tactical discussion about
> approaches to specific tasks. But you have to be there already, the
> software documentation can't get you there.
>
> > 2. Some clients would like to be able to provide a user id/password to
> our login page, but have the user id's and passwords be
> > from *their* authentication domains (i.e. corporate AD or whatever).
> The list of clients doing this is fairly small.
>
> The SP doesn't handle that in general. You would have to either design
> that into a more complex application integration so that both technical
> mechanisms can be used, or you would have hide that login mechanism behind
> a SAML IdP so that the SP doesn't see any distinction.
>
> There's a trick the SP supports where you can script a localhost callback
> feeding it some data that establishes a session, so that's a way to
> integrate a "second" login mechanism into the SP so that the application
> just sees the same integration, but it isn't heavily used. It's in the
> NativeSPBackDoor topic, but you would need to grasp the SP design much more
> than you do now to worry about that part.
>
> > I have perused the Shibboleth Wiki at great length, and am getting a
> little lost in the complexity.  It seems like a very good
> > reference, but I wasn't able to specifically locate any How-To
> documentation on my use-cases.
>
> So far you've asked about some extremely high level application
> integration considerations, none of which we could ever document for your
> system, and how to hook up additional IdPs, which is, well, frankly just
> trivial. Add metadata. Done. The devil is in the details that we can't know.
>
> > We use the user's email address as their user name
>
> That might fly for companies, but it works badly for many universities,
> FWIW. Shibboleth itself doesn't dictate any of it, you tell it what data to
> consume from the IdP and how you want to represent it.
>
> >, and that can identify the IdP for the user (after inspection: i.e. via
> the email domain) -- for client privacy reasons we are unable
> > to ask the user to select their identity provider from a list.
>
> Using a domain hook for discovery is essentially outside the SP's remit
> also, but it can be told what IdP to use at runtime when the determination
> is made. But you would have to be the one mapping domains to the IdP names
> to tell it at runtime what to do. That requires invoking the SP's Session
> Initiator endpoint with the necessary parameters.
>
> > I have done a search on Amazon and haven't been able to find a book that
> looks helpful, so any recommendations would also be
> > gratefully received.
>
> There is no book on Shibboleth. There are probably books on SAML, but I
> wouldn't know what they are or how relevant they would be to using
> Shibboleth, which approaches SAML very differently from the corporate world.
>
> -- 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/20170513/7c059346/attachment.html>