Just getting started in the world of SAML...

[Peter Schober]

* Dan G. Switzer, II <dswitzer at pengoworks.com> [2014-07-11 16:02]:
> 1. Do all HTTP requests get processed by Shibboleth SP, or just calls to 
> the specific URI patterns?

They all do, today, unless you're setting 'ShibDisable On' for some parts:
https://wiki.shibboleth.net/confluence/display/SHIB2/NativeSPApacheConfig

> 2. When using Shibboleth SP and I'll be having multiple IdPs, it appears 
> I need to use the Discovery Server.
>
> How do I push new IdPs into the Discovery Service? Can I do that from an 
> REST API, where my application can push information into the DS? We 
> ideally want to preconfigure some popular IdPs and then allow users to 
> specify their own.

Ideally by using a DS that will configure/update itself automagically
based on the SAML metadata available to your SP. The Shibboleth EDS is
a good choice for that, if you can live with the UI. Discojuice.org is
another option (but needs discojuice.org or hacking to be usable
standalone). Or the SWITCHwayf software. The SP's Discovery Feed could
also be used to roll your own UI on top of data provided by the Shib
SP.

> Can I use a central DS, or should I really use a separate DS for
> each node in my cluster? If I should install the embedded DS, what's
> the best way to propagate changes to all my servers?

The EDS does not have it's own data, it pulls a json feed from the
Shib SP's discovery feed handler. So no maintenance needed for the EDS
(only for the SP itself).

But I thought you'll follow the model of giving each customer/IDP its
own vhost? In that model don't need a DS as the pre-communicated
customer-specific application URL replaces discovery, essentially.

Let me note that if some of your customers have registered their IDPs
in Identity Federations (managing SAML metadata on behalf of all their
members) having a customer-specific vhost does not scale/work too
well.
Simply letting all use the same application and putting up a DS to
pick where to authenticate works much better here and saves work for
everyone involved.

> 3. What's the best way to handle changes in the IdP's cert? If I use a 
> centralized Discovery Server, is that the only place the certs need to 
> be? If not, is there a way to push new certs into the Service Provider 
> via an REST API?

Key rollover has nothing to do with discovery. If you give IDPs an
interface to register their metadata with you (which is what I
understood from what you wrote above) that'd also be the place where
they'd  upload new keys. How that turns into usable metadata for your
SAML SPs is then your problem (with you owning the registry).

> 4. How can I handle directing my users to the correct IdP? We need to 
> configure specific clients to go through specific IdPs that their 
> administrators configure.

By either using a DS (and letting subjects pick their IDP) or
sidesteppingn this and giving each customer/IDP it's own URL (could be
REQUEST_URI or a vhost). The latter makes federation impossible, as
hinted at above.

> 5. Considering that each client is going to communicate w/a specific 
> IdP, would I be better off just using OpenSAML and implement what I 
> need? Everything I've read said don't try to recreate the wheel, but 
> really all I need to do is generate the initial request to the IdP and 
> then process the results. Would perhaps just using OpenSAML make the 
> most sense?

I wouldn't consider writing my own SP. "All I need to do" is implement
all the features I might need, and do so securely. Why not just
install and use existing middleware that handles all that for your?
That "each client is going to communicate w/a specifific IdP" is the
normal and not a reason to implement a SAML SP by yourself.
-peter