Dr. Neil Madden is a provider of application security and applied cryptography training, through my UK-based company, Illuminated Security. I am the author of API Security in Action (Manning, 2020). Previously I was Security Architect for ForgeRock, and prior to that I was tech lead for the flagship OpenAM access management product (now ForgeRock Access Management). I have around 20 years experience as a software engineer, a PhD in Computer Science, and a love of logic programming languages. I live with my wife and daughter in Gloucestershire.
API Security in Action
I am the author of API Security in Action published by Manning. You can buy the book directly from the publisher using that link (use code fccmadden to get a discount at checkout), or from Amazon (UK, Canada). If you like it, please leave a review on Amazon as that really helps.
Like many software engineers of my generation, I started programming in the 1980s on a Sinclair ZX Spectrum +2 that my parents bought one Christmas (1987, I believe). We still had this as our only computer well beyond when all my friends had moved on to Amigas, PCs, or Sega Megadrives. Boredom with the stock of games we had led to investigating the BASIC programming environment, and I was quickly hooked. I spent countless hours typing in listings from magazines or second-hand books on building adventure games. This also introduced me early on to the joys of debugging other peoples’ code, as the listings invariably didn’t work first time. I eventually learned a little Z80 machine code, but mostly just succeeded in crashing the machine.
In 1999 I applied for a place on IBM’s Pre-University Employee programme (PUE, affectionately pronounced “pooey”). Despite a rather testy interview with a manager who seemed very disappointed that I didn’t have my entire career mapped out at 18, I was offered a place at IBM’s labs in Hursley, near Winchester. I have fond memories of that time. Hursley is an amazing location, and I couldn’t really believe that I worked there. At that time, it was also still full of amazing old engineers—I remember being asked by one to help him debug a prototype telephony card, which involved sitting with an oscilloscope and reading data from connections in the guts of the computer. This was a different level from how I’d approached computer hardware until then!
I made lots of friends at IBM, and learnt a lot about how software is actually put together. I also learned lessons in corporate exploitation, as we were paid barely enough to cover our accommodation (in a really rough part of Southampton) and given a lot of tedious grunt work that nobody else wanted to do. Nevertheless, I returned twice as an intern in the summer break during my first two years of university. Many of the more senior developers there were generous with their time and advice, though. I don’t think I’ve worked anywhere since that had such a good culture of informal mentoring.
It was at IBM that I was introduced to the Tcl scripting language, which was used in an internal testing tool called Parrot (which was used for testing voicemail and other telephony applications). I was learning Java at the time from an old copy of Java 1.1.8 on a CD-ROM that came with a book, and myself and a housemate had both developed our own versions of Tetris as applets to learn the language. I was blown away by the simplicity of Tcl. Not only could I reproduce a simple Tetris game using Tk in significantly less code than Java, but adding network play support was almost trivial. This totally blew my mind, and I’ve not really recovered since. I went on to become quite involved in the online Tcl community, authoring many articles on the blooming wiki. Among other contributions, I was responsible for the following:
- A simple approach to lambda expressions, which partly inspired TIP 194 that added lambda expressions to Tcl. (I remember having several arguments with Salvatore Sanfilipo at the time, who had an alternative proposal. Salvatore, better known as antirez, went on to design Redis, so has had a much larger impact on the world than I have!)
- Transparent OO for Tcl (TOOT), which expanded on the previous approach to lambda expressions to consider an OO-like approach to functional programming. This approach was quite influential, in that a lot of people thought it was good, but ultimately didn’t have much practical impact as far as I’m aware.
- I also got the opportunity to work with Miguel Sofer (sadly missed) on the design of Tcl’s coroutines. Miguel had been inspired by Lua’s coroutines, and had also been working on a redesign of Tcl’s interpreter that meant this kind of thing could be easily added. Miguel credited me as a co-author, but in reality he did almost all the work on that proposal. But I think, again, he was influenced by some wiki articles I’d written about continuations and closures. I wrote much of the text of the TIP, and the examples demonstrating the usefulness of this approach.
- On top of the coroutines facility, I developed a package for functional programming with generators, which was added to the standard library in 2009. (Pre-dating Java streams by 5 years, just sayin’).
This all overlapped with my university career. I started my BSc in Computer Science at the University of Nottingham in 2000 and graduated in 2003 with 1st-class honours (a bit of a fluke, as I wasn’t a very diligent student). I had an offer to return to IBM full time, and had assumed that was what I would do. But then Dr. Brian Logan suggested that perhaps I should think about doing a PhD. I was flattered by the suggestion, as nobody in my family had ever done a higher degree. After a little thought, I agreed, and ended up spending the next 6 years struggling to work out exactly what I was interested in. I initially attempted to create a computational model of Daniel Dennett’s “multiple drafts” theory of consciousness. I learned a lot from the attempt, but I felt out of my depth. After a disastrous workshop in Edinburgh (I think), where a prominent figure in the field publicly criticised me after my talk for (in her view) not sufficiently knowing previous work in the field, I decided to switch topics. It wasn’t a fun time, to say the least. I finally finished my PhD thesis, on activity recognition and “collaborative narrative” in massive online games, in 2009. During this time I became increasingly interested in programming languages and logic programming. I wrote a paper expounding the virtues of Datalog.
After briefly working as a research fellow in the Mixed Reality Lab at Nottingham, I decided to move away from Nottingham with my then fiancée. We settled in the Cotswolds, and I got a job working as a contractor for a civil service department nearby building extraordinarily baroque systems in Java Enterprise Edition. Thankfully, Java had already started moving towards more succinct annotation-driven approaches to programming (influenced by Ruby on Rails and the idea of convention over configuration), so this wasn’t as bad as it could have been. There were some good ideas in there, but also a lot of dogma and cargo-cult programming.
After a few years, I was frustrated by that job and wanted more of a challenge. In 2013, I found ForgeRock, who were still at that time an early-stage startup, trying to build a business around open-source identity and access management tools from the ashes of Sun Microsystems. I got a job as a software engineer in Bristol, working with possibly the best engineering team I’ve ever had the pleasure to work with. It was a happy time, and a great experience. There was a lot of legacy code to work with, but the team all cared deeply about engineering.
I had already developed an interest in application security, and particularly cryptography, at the time. Realising that there was a lack of deep knowledge of these topics on a team that was ostensibly writing security software, I took it upon myself to become an expert in those topics. So I spent a lot of my free time teaching myself the topics, doing Coursera’s legendary Cryptography I course (taught by Dan Boneh), and reading as many books as I could. About this time I also joined the OAuth working group at the IETF and started getting involved in security discussions there and elsewhere. I learned a lot about the process of making standards. I still contribute to the OAuth WG and the cryptographic forum research group (CFRG).
At ForgeRock, I was responsible for several technical developments that I am proud of:
- The development of bloom-filter based logout for “stateless” session cookies. This took quite a bit of “serious” engineering to design, and has had some tricky bugs over the years, but it’s extraordinarily scalable. One of ForgeRock’s largest media organisation customers uses this for managing mind-boggling numbers of user sessions during peak events.
- Multiple improvements to internal cryptography APIs in different parts of the products. Upgrading insecure encryption to modern authenticated encryption in a backwards-compatible way is hard!
- Adding support for Macaroons to ForgeRock’s OAuth 2 stack. I still think this is a great idea, but it’s not seen much traction either with FR’s customers or in the wider OAuth2 ecosystem. There are also some patents around this approach both from Google, and some from FR too (based on my work)—although I think it would be easy to avoid them.
- Developing a unified internal API for handling secrets: system credentials and cryptographic keys. This has become the standard way to handle such material across ForgeRock’s products, with pluggable backends allowing us to use secrets stored in files, or in cloud-hosted services like secret vaults or key management systems.
Eventually, ForgeRock grew big enough to become a public company and to start acquiring more and more procedures and requirements. This was good for me personally: as an early employee I had a decent amount of stock options, which I could now cash in. With that modest sum I had the financial security to leave and go it alone. Which is what I’m now doing.
I believe my experience has given me a fairly unique perspective on applied security and software development, and I intend to use that experience teaching others what I know.