General guidance for new admin

[Cantor, Scott]

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