Just getting started in the world of SAML...

Fri Jul 11 12:28:32 EDT 2014

Hi,

> I've been syncing my head into the world of SAML over the past couple of 
> days off and on. I've been a ton of reading, but I have a few questions 
> that I'm unsure of, so hopefully someone here can help me out.
> 
> First, all little background. I'm working on a SaaS application, where 
> each of our clients is a separate company which has it's own branded URL 
> to access the functionality.

We (Knodium) also operate a SaaS application. We don't have separate
logical instances / URLs for each customer but we do have certain pages
for particular customers which sport their own custom login URL which
takes them directly from that page to the appropriate IDP.

We also have a generic login page which sports eMail login and
Shibboleth Discovery Service Login.

> What we want is for clients who want to use SSO, they will define their 
> IdP when configuring their company.

We get all our metadata via a separate federation

Near the end of the mail I talk about some of the extra work you'll have
to do that our Federation does for us with respect to establishing trust.

> So with that in mind, I have a couple of questions.
> 
> 1. Do all HTTP requests get processed by Shibboleth SP, or just calls to 
> the specific URI patterns?

That depends on how you set things up. We use the FastCGI modules and
plug them into our own custom webserver. As such we can easily customise
our routing and, indeed, only the
https://www.knodium.com/Shibboleth.sso/ and
https://www.knodium.com/login/uk-federation portion of the namespace
ever routes near the Shibboleth responder or authorizer.

There are two parts: the authorizer and the responder. One just adds the
current session information to the current request and one handles the
/Shibboleth.sso/ URL space. Depending on the SP configuration file, you
can say whether a session is mandatory or not. i.e. whether if, when the
authorizer finds no session, it immediately redirects to the responder
or whether it just passes-thru' without adding any information.

If you're using the Apache (or other) integration(s) you'll have to read
up a little bit (links at the end of the mail). Personally, I found the
documentation very daunting when I first came to it but the information
is mostly all there once you know the terminology and style. :-)

At login time we flow users through the authorizers and responders as
appropriate and then we use it to initialise our own app specific
session management. After that we never consult Shibboleth again.
This works well for us but there's a downside in terms of "Single Logout
Support".

For example, when a user wants to log into Knodium with Shibboleth we
send them to this URL:

https://www.knodium.com/login/uk-federation

This URL routes to the Shibboleth Authorizer FastCGI. If there is a
session in place then it returns the details of it to our app side
handler. If not, as we've specified Shibboleth Sessions as mandatory,
the authorizer initiates a login by redirecting the user to
https://www.knodium.com/Shibboleth.sso/Login

How that URL works is described below...

> 2. When using Shibboleth SP and I'll be having multiple IdPs, it appears 
> I need to use the Discovery Server.

That depends: it sounds like you are best avoiding DS and WAYF entirely
for your particular use case.

When the responder at Shibboleth.sso/Login runs it works out how to
authenticate the user. How it does this is controlled by the <SSO ...>
directives in shibboleth2.xml.

If you set it up as a discovery service then it'll redirect the user to
the IDP picker by default.

Once the user has picked their IDP the Discovery Service redirects back
to your SP's Shibboleth.sso/Login hander: it uses a special URL
describing the IDP and then the responder redirects the user to the
specified IDP rather than showing them the picker. i.e. the user
"bounces off" rather than "passes through" the Discovery Service.

It's possible for you to build these URLs yourself such that you can
place a button on an arbitrary one of your pages that says "Login in
with IDP X".

https://wiki.shibboleth.net/confluence/display/SHIB2/NativeSPSessionCreationParameters

For example, when we decide to authenticate a user, they end up on
https://www.knodium.com/Shibboleth.sso/Login which redirects them to the
UK Federation Central Discovery Service where they can pick, for example
"Imperial College London".

If we want to initiate a login with "Imperial College London" directly,
we get the user to click a link to

https://www.knodium.com/Shibboleth.sso/Login?entityID=https://shibboleth.imperial.ac.uk/shibboleth

In order to do this you need to know which IDP corresponds to which
customer and, indeed, in our app we model both these "institutions" and
their corresponding IDPs. When the user finally logs in with the correct
IDP we also use the attributes released to determine how they are
affiliated with that institution and what they are entitled to.

On each app instance you'd provide appropriately crafted login links.

One thing to note is that I'm assuming that you only have a single SP.
This exists on a particular host with a particular URL and given that
you state that you provide a different URL for each customer's app
instance, the URL for your SP won't match the URL for the customer.
Therefore, you'll have to design your own login flows such that you can
get session data to appear in the correct way. We avoid this problem by
having our whole app and SP in the same URL space.

> 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.

As you are collecting partner metadata (for each IDP) manually, rather
than federating, you cannot benefit from a federation supplied discovery
service. If you still need a discovery service for some kind of fallback
then you'll have to build one manually or with a package such as the
Shibboleth EDS (embedded discovery service).

The Shibboleth EDS can take a JSON feed from the Shibboleth.sso/ URL
space that is automatically provided by the metadata your SP has loaded.

As you're doing metadata management anyway, you're probably better off
designing your own custom login URL generator which you can use for both
the discovery service (just list them all) and the customer login pages
(just list the relevant ones).

> 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?

Shibboleth EDS is a javascript thing which queries a URL on your SP.

You can front the SP with a number of webservers but clustering the SP
itself is a somewhat challenging job. I'd avoid clustering the SP until
you have things working and then revisit the docs at a later stage.

At Knodium the SP is only involved in the request path during an actual
Shibboleth login attempt so we only need to scale it with the number of
concurrent logins that we need to support. In practice this number is
tiny so we only need one SP for capacity.

Provided you're only directing auth requests to a single shibd at a
time, you can cover the failover case with a switch-over to another
identically configured SP instance. With a small number of concurrent
logins, a cold cache shouldn't be a problem but users will have to
re-auth with their IDP each time you switch (rather than having a login
button that automatically logs them in without prompting for credentials).

> 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?

The IDP certs are a metadata management issue. As you are managing
metadata yourself then you'll have to do this yourself but you can
extend your existing interface to allow the IDP to upload a fresh cert
and inject it into the metadata in the same was as you inject new IDPs.

What processes do you have in place to verify the original certificate
upload? When Knodium joined the UK Federation we had to verify the
fingerprint of their signing key using an out-of-band mechanism (i.e. a
phone call).

Given that the IDPs that provide you with their metadata will also have
to take a trusted feed of your SP's metadata, you need your own way of
establishing this initial trust relationship.

> 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.

I hope I answered this along the way. Let me know if you have any more
questions.

> I apologize if these are basic questions that I missed in the documentation.

No worries: it's what this list is for and whilst the documentation is
very comprehensive, it is quite difficult to get into from a standing
start. :-)

I've not linked to much of it here because I'm lazy so let me know if
you can't find an appropriate reference for anything I've talked about.

Maybe reread:

https://wiki.shibboleth.net/confluence/display/SHIB2/NativeSPEnableApplication

For the "responder" stuff:

https://wiki.shibboleth.net/confluence/display/SHIB2/NativeSPApacheConfig#NativeSPApacheConfig-MakingURLsUsedbymod_shibGetProperlyRouted

For the "authorizer" stuff:

https://wiki.shibboleth.net/confluence/display/SHIB2/NativeSPApacheConfig#NativeSPApacheConfig-EnablingtheModuleforAuthentication

and, when you're ready to implement:

https://wiki.shibboleth.net/confluence/display/SHIB2/Installation

and

https://wiki.shibboleth.net/confluence/display/SHIB2/NativeSPEnableApplication

Regards,
@ndy

-- 
andyjpb at knodium.com
http://www.knodium.com/