Just getting started in the world of SAML...

[Dan G. Switzer, II]

Andy/Peter,

Thanks for all the good info!

I'm going to take some time to make sure I've processed it all, but the
picture is becoming clearer.

-Dan


On Fri, Jul 11, 2014 at 12:28 PM, Andy Bennett <andyjpb at knodium.com> wrote:

> 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/
>
> --
> To unsubscribe from this list send an email to
> users-unsubscribe at shibboleth.net
>



-- 
Dan G. Switzer, II
dswitzer at pengoworks.com
http://blog.pengoworks.com/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://shibboleth.net/pipermail/users/attachments/20140711/7034ca95/attachment-0001.html