Have you ever burned your hands by some new and immature technology?

Question

I often hear people saying you shouldn\'t rush into adopting new technologies until they have become stable, tried and tested. There is even a joke on how it takes 3 versions to

Answer 1

AzMan (Microsoft Authorization Manager)

We started using this on a public web site/web app, enticed by dreams of single-sign-on and claims of being able to "leverage your existing infrastructure" or whatever the marketing speak now says. A drop-in solution for ASP.NET that sysadmins could manage without having to develop any tools or write any code at all. It was win-win, right?

We learned several things as a result of our decision, none of which we wanted to learn:

• Active Directory itself is not a very good choice for an authentication mechanism servicing a public web site. Not that it isn't capable - it's quite capable, but it's like hiring a Ph.D to write a "Hello World" app. It's overqualified, it does way more than you could ever need in such a context, it's much more difficult to work with than a plain old SQL table, and requires a lot more maintenance.

• AzMan is slow. Very, very slow. The role provider has to maintain a cache, which should tell you just what kind of performance we're talking about. I never did fully understand why it was so slow, but I imagine it has something to do with the hornet's nest of COM and network protocols it depends on.

• A cache (see above) can be a very dangerous thing when you have little to no control over it. When we added new users manually (i.e. through an administrative application as opposed to the site itself), those users would end up with a "not authorized" screen until the cache expired and they logged out. Sometimes this would even happen to users who self-registered online; we never did find out why.

• The tools were horrible. Take a brief look at the AzMan console if you don't believe me, or read some of the documentation if you really want a headache. Why should anything be so complicated?

• It was flaky. A lot of times the provider would just stop working, spitting out cryptic COM errors (a different one each time!) and we had to restart IIS or even the entire web server to get it to cooperate again. We also had a domain trust set up - because obviously we didn't want 50,000 public user accounts on our internal corporate domain - only problem was, administrators had to log in to administrative accounts on the secondary domain to manage roles because the console would fail in mysterious ways if you tried to use it from the primary (even as an Enterprise Admin with Domain Admin rights on the secondary domain).

• Support was practically nonexistent. If you use the basic SQL Server role provider (which we don't, but just as an example), there are 10 million tutorials and you can Google for any error message or ask any question on any forum. Whenever something went wrong with AzMan or we wanted to do something new, it was a constant struggle to find good information.

• Code integration was awkward. You had to go through a bunch of messy COM layers and the interface sucked. If I recall correctly, there was no way to just do a simple authorization check - you had to download the entire app/role registry. This was a long time ago though, so my memory might be foggy on that aspect.

Eventually we couldn't take it any longer and decided to rip out the entire system for a homegrown one based on a couple of SQL Server tables, which is probably what we should have done from the get-go. Migration was painful (see the two points above), but we got it done, and never looked back.