Category: Mobile Technology

Since we have decided to use the AD as the user management foundation for the different web applications running on the network, it’s now so easy to write applications without worry. But won’t it be nice for users to login on one application and remain in session across multiple applications just like you have on yahoo, msn, windows network, etc.? Why should a user login into different applications? It’s no consolation that the security credentials are the same.

Now, Windows have the same facilities, which is evident for those who have used Outlook Web Access (OWA). If you are authenticated against the domain in which OWA is residing, you wouldn’t be prompted to login again. I tried so much but couldn’t lay my hands on any reference. It should be some obscure ActiveX somewhere…

So, I set out to design what we call a base/foundation service (BFS) structure. This is an application that authenticates a user against the active directory and keeps the session information in a database. When a user attempts to use an application, the app queries the BFS to know if the user is logged in and what the security credentials/profiles are. An application must be registered and talks via secured connection (web service over https) before it can query the BFS. The sessions are tied to machines, and it has a scheduler that runs the timeout processes.

We use an oracle database so that the applications could survive a crash and also allows clustering. ColdFusion itself could use a database for session management in clustering.

When CF developers talk of not reinventing the wheel, we tend to quickly think of CFLIB.org, fancy web services, borrowed CFCs, commercial components like SoEditor, KTML, etc.

However, right under our noses are established frameworks that we could leverage, consequently speeding the time to market for (mostly enterprise) applications.

When I first started with CF application development, building, tweaking and supporting user administration modules for these applications was one heluva work to do. More annoyingly, users don’t want to have many usernames and password. Tracking profile changes from across the network to application privileges wasn’t fun.

Then I discovered Active Directory. Now I know that not all organizations run on AD but since Microsoft is still the dominant OS, I assume that there is a large number of AD implementations out there.

After a particular harrowing experience on my user admin modules, I sat there wondering why I couldn’t off load all my worries on AD? So I jumped into AD, LDAP and CFLDAP documentations, cooked up my code, and presto, I have a universal service interface between AD and my legion of applications.

So, if a user resigns, good, my apps bounce him out. If he leaves IT for another department, he automatically loses admin rights. User profiling is mirrored on the AD security profiles. The benefits are obvious; the network and security admins can continue their administration while the applications live their lives without breaking a sweat. Also, there is a better ROI because we don’t need to train and maintain application administrators, and there are less modules to breakdown anyway. Meanwhile, the downside is that if the AD, or my fancy interfaces have seizures, service failure epidemics will bring down the whole application ecostructure.

Over the next few posts, I will discuss more on how the interface was implemented and probably get ideas on how it could be fine-tuned in a sleeker way.