<div dir="ltr">Peter,<div><br></div><div>Thanks for the reply. That helps. I do have some follow up questions.</div><div><br></div><div>First, we actually only have a single vhost. We use wildcard DNS to identify the clients, so there's only one application.</div>
<div><br></div><div>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.</div><div><br>
</div><div>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.</div>
<div><br></div><div>I should be able to configure just the specific locations to be monitored, correct?</div><div><br></div><div>Also, so the only way I can forcefully choose the IdP for the user, is to set up specific URL patterns. There's no way for me to pass something to the SP on a redirect to specify which IdP to use?</div>
<div><br></div><div>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.</div>
<div><br></div><div>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. 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?</div>
<div><br></div><div>Thanks for all your help! It's certainly helping to clear things up.</div><div><br></div><div>-Dan</div><div><br></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Jul 11, 2014 at 10:21 AM, Peter Schober <span dir="ltr"><<a href="mailto:peter.schober@univie.ac.at" target="_blank">peter.schober@univie.ac.at</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">* Dan G. Switzer, II <<a href="mailto:dswitzer@pengoworks.com">dswitzer@pengoworks.com</a>> [2014-07-11 16:02]:<br>
<div class="">> 1. Do all HTTP requests get processed by Shibboleth SP, or just calls to<br>
> the specific URI patterns?<br>
<br>
</div>They all do, today, unless you're setting 'ShibDisable On' for some parts:<br>
<a href="https://wiki.shibboleth.net/confluence/display/SHIB2/NativeSPApacheConfig" target="_blank">https://wiki.shibboleth.net/confluence/display/SHIB2/NativeSPApacheConfig</a><br>
<div class=""><br>
> 2. When using Shibboleth SP and I'll be having multiple IdPs, it appears<br>
> I need to use the Discovery Server.<br>
><br>
> How do I push new IdPs into the Discovery Service? Can I do that from an<br>
> REST API, where my application can push information into the DS? We<br>
> ideally want to preconfigure some popular IdPs and then allow users to<br>
> specify their own.<br>
<br>
</div>Ideally by using a DS that will configure/update itself automagically<br>
based on the SAML metadata available to your SP. The Shibboleth EDS is<br>
a good choice for that, if you can live with the UI. Discojuice.org is<br>
another option (but needs <a href="http://discojuice.org" target="_blank">discojuice.org</a> or hacking to be usable<br>
standalone). Or the SWITCHwayf software. The SP's Discovery Feed could<br>
also be used to roll your own UI on top of data provided by the Shib<br>
SP.<br>
<div class=""><br>
> Can I use a central DS, or should I really use a separate DS for<br>
> each node in my cluster? If I should install the embedded DS, what's<br>
> the best way to propagate changes to all my servers?<br>
<br>
</div>The EDS does not have it's own data, it pulls a json feed from the<br>
Shib SP's discovery feed handler. So no maintenance needed for the EDS<br>
(only for the SP itself).<br>
<br>
But I thought you'll follow the model of giving each customer/IDP its<br>
own vhost? In that model don't need a DS as the pre-communicated<br>
customer-specific application URL replaces discovery, essentially.<br>
<br>
Let me note that if some of your customers have registered their IDPs<br>
in Identity Federations (managing SAML metadata on behalf of all their<br>
members) having a customer-specific vhost does not scale/work too<br>
well.<br>
Simply letting all use the same application and putting up a DS to<br>
pick where to authenticate works much better here and saves work for<br>
everyone involved.<br>
<div class=""><br>
> 3. What's the best way to handle changes in the IdP's cert? If I use a<br>
> centralized Discovery Server, is that the only place the certs need to<br>
> be? If not, is there a way to push new certs into the Service Provider<br>
> via an REST API?<br>
<br>
</div>Key rollover has nothing to do with discovery. If you give IDPs an<br>
interface to register their metadata with you (which is what I<br>
understood from what you wrote above) that'd also be the place where<br>
they'd upload new keys. How that turns into usable metadata for your<br>
SAML SPs is then your problem (with you owning the registry).<br>
<div class=""><br>
> 4. How can I handle directing my users to the correct IdP? We need to<br>
> configure specific clients to go through specific IdPs that their<br>
> administrators configure.<br>
<br>
</div>By either using a DS (and letting subjects pick their IDP) or<br>
sidesteppingn this and giving each customer/IDP it's own URL (could be<br>
REQUEST_URI or a vhost). The latter makes federation impossible, as<br>
hinted at above.<br>
<div class=""><br>
> 5. Considering that each client is going to communicate w/a specific<br>
> IdP, would I be better off just using OpenSAML and implement what I<br>
> need? Everything I've read said don't try to recreate the wheel, but<br>
> really all I need to do is generate the initial request to the IdP and<br>
> then process the results. Would perhaps just using OpenSAML make the<br>
> most sense?<br>
<br>
</div>I wouldn't consider writing my own SP. "All I need to do" is implement<br>
all the features I might need, and do so securely. Why not just<br>
install and use existing middleware that handles all that for your?<br>
That "each client is going to communicate w/a specifific IdP" is the<br>
normal and not a reason to implement a SAML SP by yourself.<br>
-peter<br>
--<br>
To unsubscribe from this list send an email to <a href="mailto:users-unsubscribe@shibboleth.net">users-unsubscribe@shibboleth.net</a><br>
</blockquote></div><br><br clear="all"><div><br></div>-- <br>Dan G. Switzer, II<div><a href="mailto:dswitzer@pengoworks.com" target="_blank">dswitzer@pengoworks.com</a></div><div><a href="http://blog.pengoworks.com/" target="_blank">http://blog.pengoworks.com/</a><br>
<div><br></div></div>
</div></div>