SecurID at U Toronto (1994-2015) - an obituary of sorts.

along with a comparative timeline


In the beginning (Nov 1993), there was a spare Sun3 server.

The Sun3 was some years beyond its original warranty, with no real hope of timely hardware support from Sun (now Oracle). It had been kept running partly because it was a complete set of spare parts for an identical Sun3 which was still in active use at the time.

This machine became the first firewall to stand guard for the new SAP R/3 systems in AMS. It was renamed "" ("Filter" for short), and it was loaded up with the open source "FireWall ToolKit" software (FWTK [1] ) from Trusted Information Systems (TIS).

One security issue of that day was the vulnerabilty of passwords to "sniffing". At that point, most network traffic was unencrypted and anyone with a direct connection to a LAN would have been able to "sniff" the LAN to watch while a neighbour typed in a password).

The Filter firewall dealt with "password sniffing" by requiring users to run the open source S/Key [2] program to generate a one-time password for each new connection (once a one-time password is entered, it's no longer valid so even if it had been "sniffed", it could never be used again).

An initial stumbling block for the Filter firewall was the SAPgui program. The early SAPgui had not been designed with proxy firewalls in mind. SAPgui expected to have direct contact with the SAP servers. To get SAPgui to work with Filter, the FWTK software was modified to poke around inside the SAPgui data stream [3] and replace the SAPgui user's address with the firewall's own address. This let the SAP server behind the firewall know who it should be talking to.


In 1994, a new version of SAPgui meant the earlier poke+replace firewall customization no longer worked. But SAPgui users still had to authenticate themselves to the Filter firewall somehow. The solution became R3verify [4] - an independent adaptable call-back scheme developed locally, with Mark Acfield writing the Windows and Mac portions using Visual Basic. R3verify had been designed to handle plain passwords and S/Key passwords. It would soon handle SecurID passcodes, as well.

Poort, Gaat:

Filter stood guard on its own for the AMS servers until the arrival ( late in 1994 ) of dedicated vendor-supported hardware for firewalling: Poort and Wachthond (IBM RS6000's running AIX) and Gaat and Ingang (Cisco 4000 routers).

Also arriving on campus in 1994: SecurID two-factor authentication. FWTK software had included support for SecurID cards by way of the SecurID/ACE programming interface [5].

The last piece of the new AMS gateway was installed in Dec 1994 when the Gaat router was put into place. Gaat had an X.25 link to SAP Inc which gave them secure access to provide remote support to AMS's SAP server software. Gaat would run until Oct 2015 when it was powered off with all the other Poort/SecurID-related hardware.


By 1998, Rogers "WAVE" (Internet over tv-cable) meant it was possible to access the campus networks from home without having to dial-in and the SSH program meant it was possible to do so securely.

The Splash firewall was built to allow SSH access to AMS from off-campus. To connect to the SAP servers, Splash users had to login with SSH and then point their SAPgui connections through their SSH tunnels [6].

Splash would later include:


By 2000, Poort's hardware (IBM-RS6000) was 5 years old. It was replaced with a pair of generic Intel servers (Mix and Toss). The new servers were configured such that one system did all the work while the other (the "hot spare") was prepared to take over if it detected that the first system had failed.

Splash was also updated with the same generic Intel hardware.

These would be the generic Intel systems which would end up running as Poort and Splash until Oct 2015.


By 2006, the software license for SecurID on MVS had become expensive. The RAG firewall (ROSI Authentication Gateway) was built to allow SecurID to be used for accessing MVS without having to actually use SecurID on MVS itself: users were to be authenticated by the RAG firewall (with its cheaper SecurID software license) and then RAG would forward the now-authenticated user connections onward to MVS.

As with Poort, RAG was a proxy firewall using FWTK. In RAG's case, users connected to MVS with TN3270 -- a Telnet terminal emulator for connection to IBM mainframes. Fortunately, the FWTK package had included a telnet proxy. But FWTK's Telnet proxy on RAG had to be very heavily modified in order to achieve its objective [7] of handling-and-replacing SecurID passcodes.

RAG's server hardware (a pair of Intel systems: dish + mop) would run until Nov 2013 when RAG was converted to a VMware virtual machine.

Sep/Oct 2013:

Aladdin's eToken (the replacement for SecurID) begins rolling out on campus in Fall of 2013.

Sep/Oct 2015:

The main SecurID server (Rascal) is disconnected in Septempber. All other firewall systems (Poort, Splash, CAN, Gaat) are powered off in October having lasted at least three time longer than expected.

various gory details:
[1] FWTK
FWTK is a proxy firewall package -- in order to connect to servers behind the firewall, users must connect to the firewall itself and then the firewall connects to the servers. In 1993, VPNs and transparent firewalls were not yet available.

[2] S/Key

[3] SAPgui
SAPgui used/uses its own binary data format. SAPgui communication streams had to be analyzed byte-by-byte to find the position of the user address. Fortunately, that address was always to be found in the same position in the stream so it was possible to use a template for swapping the user address with the firewall address.

[4] R3verify

A user on Windows (and later on Mac) would start a "listener" program just before starting the SAPgui itself. Upon receiving the SAPgui connection from the user, the firewall would:

[5] SecurID API
SecurID/ACE provided Sun4/Sparc-compatible binaries to allow developers to compile SecurID support into their programs. However Filter was a Sun3 (Motorola-68020, not Sparc) and the first Poort was an IBM RS6000. Fortunately, SecurID/ACE also provided API source code to allow FWTK to be recompiled on Filter+Poort with SecurID support. This API source would be used again later when FWTK and SecurID had to be ported to Intel platforms.
[6] Splash
Splash users would launch their SSH client with specific port-relays configured. Splash users would then point their SAPgui connections to the local side of their SSH connection. The SAPgui traffic would be encrypted within the SSH connection. When the SAPgui traffic "emerged" from the tunnel on the Splash side, Splash would forward that traffic onward to its appropriate destination.

SSH customizations for Splash:

[7] RAG
RAG's TN3270 proxy customization: