What happened to MITREid Connect?
MITREid Connect was, at one time, one of the top open source implementations of OpenID Connect and OAuth 2.0. Written in Java and targeted for enterprise systems in the days before cloud services, it fit a niche and did it well. Where is it today and where is it going?
How It Started
Back in what feels like the long-distant past, I started a research project at my then-employer to investigate federated identity and how it could be applied in our environments.
We started out by building a very slapdash but functional implementation of OpenID 2.0 (and its various extensions, like SREG and AX), and we called it MITREid because I’m not great at coming up with good names. This little experimental server got hooked into our enterprise identity management system, and it did a pretty good job at giving us a single-sign-on experience that wasn’t just prompting for the user’s password and checking against LDAP, like every other app at the time had been doing.
When OAuth 2.0 and OpenID Connect started development, I proposed a research project that would get us involved in the creation of those standards and come up with an implementation of them that we could use ourselves and give back to the community as an open source project. The result of this was the MITREid Connect project, with its flagship OpenID Connect IdP and OAuth 2.0 AS built as a Java Spring application. And as you can see, my skill at naming projects continues to shine here.
How It Went
We built MITREid Connect to fit into much the same kind of environment that the original MITREid OpenID 2.0 server.
- No internal user management, this would be handled by the corporate identity management system and plugged in through a service layer
- Pluggable authentication, so we could adapt it to whatever the corporate system and our customer environments had in place already
- Strict adherence to the standards, and a decent attempt to implement as much of them as we could manage
- Deployable in a Java servlet container, which is the kind of deployment we had readily available to us at the time
All of these goals shaped the project that came out of the research effort, and it was decently successful for its time. We released several major revisions of the project, implemented new-fangled security mechanisms like PKCE, and deployed it to both our corporate network and a number of other systems. It gave us login, API access, and a common security layer right at a time when things were shifting away from HTTP Basic Auth for everything.
When the OpenID Foundation started to make their conformance testing available, we were among the first to certify and submit our results. I even have the t-shirt to prove this!
While I was still an employee at MITRE, the MITREid Connect project was funded largely through the research program that started it. When I first founded Bespoke Engineering and started consulting full time, I fully expected that support, development, and deployment of MITREid Connect was going to be one of my major business lines, and that this would help the project continue. This was slightly true at first, with several large clients bringing me on board to help work on larger projects that were making use of MITREid Connect. However, most of my time on these projects was spent not on the MITREid Connect code itself, but on separate or larger parts of the overall project.
Not long after I left MITRE, some folks at MIT offered to host the project as part of a new consortium. This was a good relationship, but they couldn’t offer the kind of support for an engineering team that the MITRE research program once afforded. That consortium eventually folded into something else, and the MITREid Connect project was left on a shelf.
Eventually, even these lines drifted away, and my time was taken up by other efforts, and MITREid Connect became something I engaged less and less with. The handful of people that had worked on it even had plans to re-brand the project away from its MITRE roots, but even that small step never came to fruition.
Somewhere in that time, the world of computing and security shifted radically. MITREid Connect’s model of a heavyweight Java servlet no longer fit with the cloud-native hosted or even semi-hosted services that people are interested in using. Where once it was common for a large company to have its own data centers for computation power, it now seems crazy to not use a hosted cloud environment for your infrastructure. MITREid Connect was made for an on-premises perimeter-driven world, and that world has largely gone.
How It’s Going
MITREid Connect never really made the transition out of that world, and it shows in the code. It’s more than just its packaging as a Java servlet, it’s how sessions and data storage are handled, how scaling would function, and so on and so on. The dependencies stopped being updated, it was never repackaged — at least not by the core development crew — and it was never really brought up to speed with the rest of the world.
These days, MITREid Connect is not actively developed or maintained by any of the core developers, including myself. The main reason for this is simple: the people who were willing to pay for the work stopped asking for it and turned to other solutions. Most groups, including MITRE, have turned to cloud-hosted solutions to handle their entire identity stack. Or they’ve moved to other implementations, both open source and proprietary.
Even so, I wouldn’t call the project abandoned, exactly. It still exists and it still runs, and people still use it. But the core project’s dependencies haven’t been updated in quite some time and there’s nobody in the queue to manage that. The project has been forked a number of times, and some of those forks look like they’re still active, but I honestly don’t know which one I’d point someone to.
In conclusion, if you’ve found MITREid Connect and it works for you, that’s awesome, go to town! It’s immensely customizable and configurable, and the core is stable, solid, and thoroughly tested in more implementations than I know of. But if you’re looking for it to do something new, or to be deployed in your cloud container, I have to say you might want to look towards something else for a solution.
