Just getting started in the world of SAML...

[Peter Schober]

* Dan G. Switzer, II <dswitzer at pengoworks.com> [2014-07-11 16:59]:
> First, we actually only have a single vhost. We use wildcard DNS to
> identify the clients, so there's only one application.

I don't understand what that means. If anything.yourdomain.com and
everything.yourdomain.com gets people into your application you have
two vhosts. How that's done in DNS (with individual A records, or
CNAME records or wildcards) doesn't matter. With wildcards you
essentially have unlimited numbers of vhosts, all of which need to be
known to the relevant IDPs in order for them to be able to send your
SP SAML protocol messages.
(Ignoring the special case that your SP could sign authentication
requests and /all/ SAML IDPs can use signed authnRequests as a
replacemet for ACS URLs in SAML metadata.)

> What I'm hoping is that I can set up some specific URL patterns and only
> those patterns are processed by the SP. I basically want something like
> /sso/saml/login and /sso/saml/logout.

Sure, no problem (modulo the logout part, cf. SLOIssues in the wiki).

> When the "login" pattern is hit, we'd go through the SAML authentication
> and once the user has been authenticated, we'll basically pass the user
> over to our own authentication/session management. Since only a very small
> subset of clients would use SAML, I want to minimize the overhead. Plus,
> once we authenticate we really are driving all future requests through our
> establish system.

I already told you the setting to keep the overhead minimal and the
documentation for it, too.

> I should be able to configure just the specific locations to be monitored,
> correct?

If you mean you can setup your webserver to require Shibboleth
sessions for specific resources (Location, Directory, etc.), then yes,
certainly.

> Also, so the only way I can forcefully choose the IdP for the user, is to
> set up specific URL patterns.

Is that an assertion on how the Shib SP works (which is false) or a
constrained of your intended deployment? If the latter there are many
ways to do that.

> There's no way for me to pass something to the SP on a redirect to
> specify which IdP to use?

Sure is, e.g. by using the Login initiator and passing it an entityID
parameter with the IDP's entityID, see
https://wiki.shibboleth.net/confluence/display/SHIB2/NativeSPSessionInitiator
and
https://wiki.shibboleth.net/confluence/display/SHIB2/NativeSPContentSettings

> I was really hoping to take directing users to a DS out of the equation.
> It's a usability issue. The people signing in, won't know what IdP to
> choose--which is why we want to just force them to their correct IdP.

If you know the IDP the user wants to authenticate at you don't need
am IDP Discovery Service (D'oh!), which you'll only need if you have
yet to determine (discover) the IDP to be used.

In deployment models that support federation well you don't encode the
IDP into the vhost or the application access URL -- which both rely on
pre-communicating the correct access URL to the IDP and its users --
and so need other methods to determine the IDP (i.e., IDP discovery).

> It also sounds from your response, that the Shibboleth SP doesn't
> have an easy way of getting IdP metadata into the SP--other than the
> XML.

The XML is the metadata. But yes, the Shib SP (and IDP) do not provide
proprietary interfaces to get the same info into the software which is
specified in the SAML 2.0 Metadata spec.

> So if I'm going to allow users to define their IdP, we're going to
> need a way to propage all changes to all the SPs in our
> cluster. Correct?

Correct. If you're registering and managing SAML metadata for IDPs (to
be used by your own SPs) you'll have to give the resulting SAML
metadata to all your SPs.
The Shib SP (like the IDP) has metadata providers which make the
automated refreshing part trivial.

How you produce that metadata (and distribute it to your SPs securely)
is up to you. One way is to sign (XMLdsig) the SAML metadata and put
it up on a web server of yours, to be regularly pulled by all your
SPs. Another would be to commit it into a VCS and distribute it to
your SPs that way. Or via messaging systems. Or configuration
magagement systems. Or any other way.

If you don't want to roll your own metadata registration system from
scratch there are a couple of those around, btw, like PEER or
Jagger/RR3.
-peter