The Johnson Blog

The other day I realized I have what seems to be an ackward way of going about designing (at a high level) software. When presented with a problem (requirements, etc) that I need to solve, it doesn’t seem like I really put my brain to work on it. I find myself putzing around, shufling papers, surfing the web, reading, etc.. instead of actively “working” on the problem at hand. Every now and then I will check-in on the problem in my head and see if I see the answer. If not, it’s back to doing whatever else I was doing.

That will continue for a few days, while I feel like I’m half-asleep and in a stupor. Inevitably, the solution will form in my head without me having actively focused on it. It’s almost as if I don’t want to brute-force an answer, but let it stew until the answer presents itself.

The past several projects at work have been like that. The outcomes have been interesting and have worked very well, so I suppose this approach isn’t a problem. Sure feels a little strange though.

Anyone else do this?

As a software developer I’ve stayed far away from anything having to do with Active Directory. That’s for the network guys! That’s what I’ve always thought at least, until last week.

That’s when I began doing some research for an application’s Authentication and Authorization system. I kept coming back to the Microsoft recommended approach of storing application user information in a directory service, but I didn’t want to have the application require an Active Directory or, worse, require customers to apply schema changes to their AD (something I’d expect to be met with a lot of resistance).

Then I discovered Active Directory Application Mode, ADAM for short. It provides essentially the same functionality (from an application’s viewpoint) as its big brother – you can extend the schema with custom classes and attributes, assign security rights, authenticate users, etc., all without impacting an organization’s infrastructure.

Now an application can be installed with its own directory service. Regarding users, it can be its own user store (ADAM Users) and/or reference domain accounts. This is exactly the functionality we need, the ability to have domain and non-domain accounts co-exist in a clean manner, with the ability to store information on each without requiring the customer to change their AD schema. I’m very excited about using ADAM, it seems to fit exactly where we need and should supply a solid (and standard) foundation for our Authorization and Authentication system. Pretty cool if you ask me.