Over the years, our Iceni servers have undergone a number of design changes in order to accommodate the changing nature of devices being used on networks. In particular, authentication of web traffic has needed special attention constantly.
In the old days, software usually had really good support for authenticating with web proxy servers. Windows clients would silently authenticate each web request using NTLM or Kerberos, non-Windows stuff used HTTP Basic authentication (it pops up a username/password box when you start a session, but you can use the "remember password" checkbox to stop this getting annoying). Every so often we came across a rare example of software that couldn't handle proxy authentication and we'd have to tweak the proxy configuration a bit to bypass the authentication and filtering, but in general life was good.
We're increasingly seeing software support for web proxy servers getting poorer though - quite a lot of software just plain ignores the system-wide settings and bypasses the proxy, and an increasing amount of software can't handle proxy authentication at all. In fact, this latter point has often shown just how poorly built some of the modern software is: Windows 8, for example, tries to log in to login.live.com when you log into a machine, and if the proxy asks for authentication the machine hangs and has to be hard-reset! Apple devices seem particularly bad too - if the proxy asks an iPhone to authenticate when it tries to synchronise its calendar, it just retries immediately, and keeps going indefinitely - hundreds of times a second!
A few years ago we did a lot of work to work around these broken devices: Firstly we introduced a transparent proxy to deal with the software that completely ignores the proxy settings. Then we started caching the last known user for each IP address and for client software that's known to be broken, we just reused those details rather than asking them to authenticate. We also added a captive portal and support for WISPr authentication to help the Apple devices along a bit.
Along the way we his some surprising problems - for example, you would expect every web request to be independent of each other, but we found that if we avoided authenticating certain iPhone traffic, then completely unrelated traffic from that device that would usually work fine suddenly stopped being able to cope with authentication too!
The move to Iceni 2 saw more changes - administrators can now tell the system to only use the captive portal/WISPr authentication for certain problem URIs, or disable authentication entirely in some cases. For example, by default Iceni 2 servers don't authenticate of filter login.live.com.
All this work has gone a long way to avoiding the problems that were cropping up, but increasingly there's a feeling that things like phones and tablets have such poor support for HTTP proxy authentication that its probably preferable to turn it off entirely for those devices and rely on the captive portal and WISPr. But how do you do that just for those devices, and not for things like the on-domain Windows machines which still work fine?
This brings me on the the latest stuff I've just finished working on and is now going through QA testing (soon to be released to the customers, all being well!): We now allow you to define a network - a network address and netmask - and drop it into a user group as if it were a user. This means you can do stuff like disabling authentication for all devices on a particular network - your wifi network, for example.
The bonus of this is that, if your network is split up appropriately, you can also tweak filtering based on the workstation's location - you can relax the filtering for class rooms that are well supervised, for example.
We've also got rid of the "Guest" user and renamed the "Guests" group to "Anonymous" to better reflect what it means.
Over all I really like the new model, and I have plans to extend it to the mail server component as well.
However, my new job for today is to fix a locking bug in the web filter - joy of joys!
No comments:
Post a Comment