MTU ISO - Background

Why did MTU develop its own system?

There are a few reasons behind this. The most important one being a similar system didn't exist when this was written. There were, especially, none that used LDAP. There was, however, an Apache module written by called auth_ldap that did almost everything we wanted. The only thing missing was the ability to have a central login site so a password was only asked for once. Rather than develop an entire new system from scratch MTU decided to piggy back on the auth_ldap code written by Rudedog. The authorization piece was left unmodified while the login code was wrapped so that the module could work as if it were unmodified.

Another reason for developing a solution "in house" was control. Solutions that were non-LDAP compliant were looked at, but none of them fit what we were trying to do here. Even if a solution was close it wasn't flexible enough to handle our future needs. Also, a lot of the solutions were costly and would tie us to a specific vendor which also limited flexibility and control.

One final reason is security. Many of the solutions looked at used the "set a cookie" model, but many of them never tried to protect that cookie. The MTU ISO model uses an X.509 certificate in its payload which provides built in tamper proof protection through public/private key technology. It also uses strong encryption ciphers to protect the payload. The only problem left, which was just recently solved, was replay attacks. If user A obtains user B's cookie/ISO credential, then user A could become user B fairly easily. This has been worked around rather effectively, though there is still the possibility of a very specific man-in-the-middle attack. However, this particular attack would be extremely difficult to execute due to the technical difficulty and the limited time frame it would have to occur in.