<div dir="ltr"><div>Andy/Peter,</div><div><br></div>Thanks for all the good info!<div><br></div><div>I'm going to take some time to make sure I've processed it all, but the picture is becoming clearer.</div><div><br>
</div><div>-Dan</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Jul 11, 2014 at 12:28 PM, Andy Bennett <span dir="ltr"><<a href="mailto:andyjpb@knodium.com" target="_blank">andyjpb@knodium.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,<br>
<div class=""><br>
> I've been syncing my head into the world of SAML over the past couple of<br>
> days off and on. I've been a ton of reading, but I have a few questions<br>
> that I'm unsure of, so hopefully someone here can help me out.<br>
><br>
> First, all little background. I'm working on a SaaS application, where<br>
> each of our clients is a separate company which has it's own branded URL<br>
> to access the functionality.<br>
<br>
</div>We (Knodium) also operate a SaaS application. We don't have separate<br>
logical instances / URLs for each customer but we do have certain pages<br>
for particular customers which sport their own custom login URL which<br>
takes them directly from that page to the appropriate IDP.<br>
<br>
We also have a generic login page which sports eMail login and<br>
Shibboleth Discovery Service Login.<br>
<div class=""><br>
<br>
> What we want is for clients who want to use SSO, they will define their<br>
> IdP when configuring their company.<br>
<br>
</div>We get all our metadata via a separate federation<br>
<br>
Near the end of the mail I talk about some of the extra work you'll have<br>
to do that our Federation does for us with respect to establishing trust.<br>
<div class=""><br>
<br>
> So with that in mind, I have a couple of questions.<br>
><br>
> 1. Do all HTTP requests get processed by Shibboleth SP, or just calls to<br>
> the specific URI patterns?<br>
<br>
</div>That depends on how you set things up. We use the FastCGI modules and<br>
plug them into our own custom webserver. As such we can easily customise<br>
our routing and, indeed, only the<br>
<a href="https://www.knodium.com/Shibboleth.sso/" target="_blank">https://www.knodium.com/Shibboleth.sso/</a> and<br>
<a href="https://www.knodium.com/login/uk-federation" target="_blank">https://www.knodium.com/login/uk-federation</a> portion of the namespace<br>
ever routes near the Shibboleth responder or authorizer.<br>
<br>
There are two parts: the authorizer and the responder. One just adds the<br>
current session information to the current request and one handles the<br>
/Shibboleth.sso/ URL space. Depending on the SP configuration file, you<br>
can say whether a session is mandatory or not. i.e. whether if, when the<br>
authorizer finds no session, it immediately redirects to the responder<br>
or whether it just passes-thru' without adding any information.<br>
<br>
If you're using the Apache (or other) integration(s) you'll have to read<br>
up a little bit (links at the end of the mail). Personally, I found the<br>
documentation very daunting when I first came to it but the information<br>
is mostly all there once you know the terminology and style. :-)<br>
<br>
<br>
At login time we flow users through the authorizers and responders as<br>
appropriate and then we use it to initialise our own app specific<br>
session management. After that we never consult Shibboleth again.<br>
This works well for us but there's a downside in terms of "Single Logout<br>
Support".<br>
<br>
<br>
For example, when a user wants to log into Knodium with Shibboleth we<br>
send them to this URL:<br>
<br>
<a href="https://www.knodium.com/login/uk-federation" target="_blank">https://www.knodium.com/login/uk-federation</a><br>
<br>
This URL routes to the Shibboleth Authorizer FastCGI. If there is a<br>
session in place then it returns the details of it to our app side<br>
handler. If not, as we've specified Shibboleth Sessions as mandatory,<br>
the authorizer initiates a login by redirecting the user to<br>
<a href="https://www.knodium.com/Shibboleth.sso/Login" target="_blank">https://www.knodium.com/Shibboleth.sso/Login</a><br>
<br>
How that URL works is described below...<br>
<div class=""><br>
<br>
<br>
<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>
</div>That depends: it sounds like you are best avoiding DS and WAYF entirely<br>
for your particular use case.<br>
<br>
When the responder at Shibboleth.sso/Login runs it works out how to<br>
authenticate the user. How it does this is controlled by the <SSO ...><br>
directives in shibboleth2.xml.<br>
<br>
If you set it up as a discovery service then it'll redirect the user to<br>
the IDP picker by default.<br>
<br>
Once the user has picked their IDP the Discovery Service redirects back<br>
to your SP's Shibboleth.sso/Login hander: it uses a special URL<br>
describing the IDP and then the responder redirects the user to the<br>
specified IDP rather than showing them the picker. i.e. the user<br>
"bounces off" rather than "passes through" the Discovery Service.<br>
<br>
It's possible for you to build these URLs yourself such that you can<br>
place a button on an arbitrary one of your pages that says "Login in<br>
with IDP X".<br>
<br>
<a href="https://wiki.shibboleth.net/confluence/display/SHIB2/NativeSPSessionCreationParameters" target="_blank">https://wiki.shibboleth.net/confluence/display/SHIB2/NativeSPSessionCreationParameters</a><br>
<br>
<br>
For example, when we decide to authenticate a user, they end up on<br>
<a href="https://www.knodium.com/Shibboleth.sso/Login" target="_blank">https://www.knodium.com/Shibboleth.sso/Login</a> which redirects them to the<br>
UK Federation Central Discovery Service where they can pick, for example<br>
"Imperial College London".<br>
<br>
If we want to initiate a login with "Imperial College London" directly,<br>
we get the user to click a link to<br>
<br>
<a href="https://www.knodium.com/Shibboleth.sso/Login?entityID=https://shibboleth.imperial.ac.uk/shibboleth" target="_blank">https://www.knodium.com/Shibboleth.sso/Login?entityID=https://shibboleth.imperial.ac.uk/shibboleth</a><br>
<br>
<br>
In order to do this you need to know which IDP corresponds to which<br>
customer and, indeed, in our app we model both these "institutions" and<br>
their corresponding IDPs. When the user finally logs in with the correct<br>
IDP we also use the attributes released to determine how they are<br>
affiliated with that institution and what they are entitled to.<br>
<br>
<br>
<br>
On each app instance you'd provide appropriately crafted login links.<br>
<br>
<br>
One thing to note is that I'm assuming that you only have a single SP.<br>
This exists on a particular host with a particular URL and given that<br>
you state that you provide a different URL for each customer's app<br>
instance, the URL for your SP won't match the URL for the customer.<br>
Therefore, you'll have to design your own login flows such that you can<br>
get session data to appear in the correct way. We avoid this problem by<br>
having our whole app and SP in the same URL space.<br>
<div class=""><br>
<br>
<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>As you are collecting partner metadata (for each IDP) manually, rather<br>
than federating, you cannot benefit from a federation supplied discovery<br>
service. If you still need a discovery service for some kind of fallback<br>
then you'll have to build one manually or with a package such as the<br>
Shibboleth EDS (embedded discovery service).<br>
<br>
The Shibboleth EDS can take a JSON feed from the Shibboleth.sso/ URL<br>
space that is automatically provided by the metadata your SP has loaded.<br>
<br>
As you're doing metadata management anyway, you're probably better off<br>
designing your own custom login URL generator which you can use for both<br>
the discovery service (just list them all) and the customer login pages<br>
(just list the relevant ones).<br>
<div class=""><br>
<br>
<br>
> Can I use a central DS, or should I really use a separate DS for each<br>
> node in my cluster? If I should install the embedded DS, what's the best<br>
> way to propagate changes to all my servers?<br>
<br>
</div>Shibboleth EDS is a javascript thing which queries a URL on your SP.<br>
<br>
You can front the SP with a number of webservers but clustering the SP<br>
itself is a somewhat challenging job. I'd avoid clustering the SP until<br>
you have things working and then revisit the docs at a later stage.<br>
<br>
At Knodium the SP is only involved in the request path during an actual<br>
Shibboleth login attempt so we only need to scale it with the number of<br>
concurrent logins that we need to support. In practice this number is<br>
tiny so we only need one SP for capacity.<br>
<br>
Provided you're only directing auth requests to a single shibd at a<br>
time, you can cover the failover case with a switch-over to another<br>
identically configured SP instance. With a small number of concurrent<br>
logins, a cold cache shouldn't be a problem but users will have to<br>
re-auth with their IDP each time you switch (rather than having a login<br>
button that automatically logs them in without prompting for credentials).<br>
<div class=""><br>
<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>The IDP certs are a metadata management issue. As you are managing<br>
metadata yourself then you'll have to do this yourself but you can<br>
extend your existing interface to allow the IDP to upload a fresh cert<br>
and inject it into the metadata in the same was as you inject new IDPs.<br>
<br>
What processes do you have in place to verify the original certificate<br>
upload? When Knodium joined the UK Federation we had to verify the<br>
fingerprint of their signing key using an out-of-band mechanism (i.e. a<br>
phone call).<br>
<br>
Given that the IDPs that provide you with their metadata will also have<br>
to take a trusted feed of your SP's metadata, you need your own way of<br>
establishing this initial trust relationship.<br>
<div class=""><br>
<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>I hope I answered this along the way. Let me know if you have any more<br>
questions.<br>
<div class=""><br>
<br>
<br>
> I apologize if these are basic questions that I missed in the documentation.<br>
<br>
</div>No worries: it's what this list is for and whilst the documentation is<br>
very comprehensive, it is quite difficult to get into from a standing<br>
start. :-)<br>
<br>
I've not linked to much of it here because I'm lazy so let me know if<br>
you can't find an appropriate reference for anything I've talked about.<br>
<br>
<br>
Maybe reread:<br>
<br>
<a href="https://wiki.shibboleth.net/confluence/display/SHIB2/NativeSPEnableApplication" target="_blank">https://wiki.shibboleth.net/confluence/display/SHIB2/NativeSPEnableApplication</a><br>
<br>
<br>
For the "responder" stuff:<br>
<br>
<a href="https://wiki.shibboleth.net/confluence/display/SHIB2/NativeSPApacheConfig#NativeSPApacheConfig-MakingURLsUsedbymod_shibGetProperlyRouted" target="_blank">https://wiki.shibboleth.net/confluence/display/SHIB2/NativeSPApacheConfig#NativeSPApacheConfig-MakingURLsUsedbymod_shibGetProperlyRouted</a><br>
<br>
<br>
For the "authorizer" stuff:<br>
<br>
<a href="https://wiki.shibboleth.net/confluence/display/SHIB2/NativeSPApacheConfig#NativeSPApacheConfig-EnablingtheModuleforAuthentication" target="_blank">https://wiki.shibboleth.net/confluence/display/SHIB2/NativeSPApacheConfig#NativeSPApacheConfig-EnablingtheModuleforAuthentication</a><br>
<br>
<br>
<br>
<br>
and, when you're ready to implement:<br>
<br>
<a href="https://wiki.shibboleth.net/confluence/display/SHIB2/Installation" target="_blank">https://wiki.shibboleth.net/confluence/display/SHIB2/Installation</a><br>
<br>
and<br>
<br>
<a href="https://wiki.shibboleth.net/confluence/display/SHIB2/NativeSPEnableApplication" target="_blank">https://wiki.shibboleth.net/confluence/display/SHIB2/NativeSPEnableApplication</a><br>
<br>
<br>
<br>
<br>
Regards,<br>
@ndy<br>
<span class="HOEnZb"><font color="#888888"><br>
--<br>
<a href="mailto:andyjpb@knodium.com">andyjpb@knodium.com</a><br>
<a href="http://www.knodium.com/" target="_blank">http://www.knodium.com/</a><br>
</font></span><div class="HOEnZb"><div class="h5"><br>
--<br>
To unsubscribe from this list send an email to <a href="mailto:users-unsubscribe@shibboleth.net">users-unsubscribe@shibboleth.net</a><br>
</div></div></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>