Posted on
by

So, it’s been a frustrating few days debugging a supposedly simple single sign-on handshake conducted over SAML.

Further to my last post, here are a couple of gotchas that tripped me up.

Watch your session settings

If you’re using sessions, you need to make damn sure your cookie settings are the same in both your app and SimpleSAML’s config.php.

Sadly, this isn’t always possible, at least not without making an offering to the Elder Gods. SimpleSAMLPHP’s settings are fiddly, and in the time I was poking at it, I couldn’t find a way of getting it to entirely match the application’s more enhanced security settings (we, for example, stipulate various ini flags and up the session’s hash algorithm).

SimpleSAMLPHP also seems to have a habit of generating its own session ids, although I might have been blinking at the source too long.

Either way, I ended up commenting out the session initialisation code in SessionHandlerPHP::__construct() and replacing every instance of the session starting code with a call to the app’s session initialisation code.

This adds some maintenance debt, but life is too short.

Debug in incognito mode

If you’ve been banging your head against session problems for long, you’ll have a lot of cruft in your cookie jar.

A hard learnt lesson (obvious in hindsight) was that even if the code works, it’ll likely fail with our old friend Exception: The POST data we should restore was lost.

The simplest way of ensuring you’re going to be clicking through with a fresh session is to use your browser’s incognito mode to test, and after each test shut down all of these windows (they share a context, so you’ve got to close all tabs and windows to fully clear the context) and open a new one.

Hopefully this might save you some time and frustration.

Posted on
by

Just a quicky for those who are trying to integrate SAML authentication into their app using SimpleSAMLPhp.

Here’s the problem: You’ve set up your client SP, and you’re talking to a remote IdP. You’ve tested your authentication using the SimpleSAML web interface on your SP, but whenever you try it from your app, you hit an exception.

SimpleSAML_Error_Error: UNHANDLEDEXCEPTION
Backtrace:
0 /path/to/simplesamlphp-1.13.2/www/module.php:179 (N/A)
Caused by: Exception: The POST data we should restore was lost.
Backtrace:
1 /path/to/simplesamlphp-1.13.2/modules/core/www/postredirect.php:38 (require)
0 /path/to/simplesamlphp-1.13.2/www/module.php:134 (N/A)

Assuming no esoteric input filtering, the problem is likely to be in your cookie settings.

If your app creates its own session, it is likely to be creating its own cookie with its own name. E.g.

session_name('FooApp');

You must modify your SimpleSAMLPHP config to use the same session name by modifying config.php and setting 'session.phpsession.cookiename' => 'FooApp' to match.

Simple… but it took me quite a while of being convinced I’d screwed up the server config to track down!

Hope this saves someone some time.

Posted on
by

Over the past few months I’ve ended up, for reasons out of my control, becoming much more of a digital nomad than I had planned for.

I’ll write more about that in a bit I’m sure, but right now I wanted to share with you a very specific tip that came in use for me.

To track time spent working on client work, I use the linux utility hamster. There are web based ones of course, but this was simple and does exactly what I wanted to do, but the downside is that it was one computer only.

This wasn’t a problem for the most part, since I almost always worked using my home desktop machine. However, I’m now spending much more time on client site, or otherwise on my (rather old and in need of an upgrade) laptop. This meant I would always remember to keep my tracker updated, and it also made generating invoices were a problem.

Luckily, Hamster uses a simple file to store it’s tracking data, so all that was required was to find a way of sharing it. I already had an ownCloud server (if you want to use NSA file storage, you can use Dropbox if you like), so all I had to do was move the hamster db directory, and then symbolically link to it on all my machines, as so:

On your main machine (the one with the most up to date db)…

cd ~/.local/share
mv hamster-applet ~/ownCloud/
ln -s ~/ownCloud/hamster-applet

Let ownCloud sync up, and then on your client machines…

cd ~/.local/share
mv hamster-applet hamster-applet-orig
ln -s ~/ownCloud/hamster-applet

If you’re using Dropbox, obviously change the path name accordingly.

Hope you find this as useful as I have!