James McGovern’s blog recently made mention of Identity Engines, the company I work for. The mention was in the context of when appliances made sense for identity. I thought I might take a moment to explain a bit more about what our product does and then perhaps we can have more dialogue about the suitability of appliances. The current product we make is a 1RU appliance focused on the network identity space. The product ties together back-end directories with the network access devices that provide connectivity (This primarily means linking wired, wireless, and VPN access points with directories like LDAP and Microsoft AD.) Once tied together, we enable rich policy decisions to be made around what sort of network access a user should be granted and under what conditions. This is contrasted with the application identity management market which not a space we’re playing directly in today.
We chose an appliance form factor primarily for ease of use by the network operators which typically deploy our product. These individuals generally have little interest or time to install and maintain an OS on a server and additionally the application which runs on it. Running on an appliance also lets us do some basic things to protect the information contained within, such as hardening the OS and using an encrypting file system. In the network security world you generally see the delivery vehicle of a particular security technology evolve over time. First it is found in software on a general purpose OS, then it is found in an appliance, and finally it is available integrated into the network infrastructure (running on routers and switches). This evolution has happened several times now in the industry (firewalls, VPNs, IDS/IPS). What drives the transition from one platform to another has a lot to do with the maturity of the technology and the market.
(As an aside, I completely agree with James’ comment about the potential usefulness of XACML. Policy portability could have all sorts of benefits in the near future.)