Public Website Admin Tools: Divide and Conquer

One of the first steps when designing a web application is figuring out how to administer the beast and where these admin tools should live. Often this comes down to one key question: should the public website itself also be the administrative tool? While there is no single approach that works in every situation, I generally find that keeping the administrative tools separate makes more sense than embedding the tools within the public facing website. Key reasons for attacking this problem this way are:

Differing Nature of the Beasts

Public-facing websites and website administrative tools are, by nature, fundamentally different sorts of applications. Your public-facing website needs to be highly accessible to any number of browsers, platforms and users; it should be highly standards compliant and Google-friendly. From a development perspective, scalability is a massive concern. This means things like completely disabling ViewState and arguably session state, or avoiding such useful tools as ASP.NET AJAX UpdatePanels in preference to much more streamlined scripting.

On the other hand, your administrative tools are likely aimed at a very small set of users on controllable platforms. Bandwidth usage is likely not a major concern, nor are niceties like standards compliance, accessibility and search engine optimization. You can feel much freer to let ASP.NET be ASP.NET and not worry about large ViewState sizes, go ape with UpdatePanels and have massive Session variables and otherwise pretend you are a desktop developer. Its fun and invigorating, not to mention helpful in speeding the development process.

It is far more efficient to just treat each application separately up-front and not have to worry about either limiting your toolset to keep the admin tools nice and public facing nor compromising the goals of the site to keep the admin tool development sane.

Project Management

One fact of life is that issues of importance to the executive types, such as “how will this website look” tend to get delayed beyond all possible belief. Whereas mundane issues, such as “how will this website work” tend to be solved much earlier in the process. Now, if both your logical tools and workflow are dependant upon those executive layer questions, then you can end up in a bit of a bind as you cannot really start significant construction until the big-wigs actually pay attention to the project they requested. But, if you have separated things, you can have a working admin tool before anyone has taken those tough decisions on exactly which shade of pink to use.

Another advantage is, if you have the resources, it becomes much easier to separate the labor between different members of your team as they need not be futzing about the same bits of code. Finally, 3 years down the road, you can give the public website a facelift without messing around with the much more development resource intensive tools.

Security

Using a completely separate application for administration opens up a lot of security options. First, from an IIS perspective, it is much easier to force the administrative application to live under SSL on the web server level. Second, for those of us in the tin-foil hat crew, you can further beef up the transport-layer security by restricting access to the admin tools. This can range from placing them behind a VPN to keeping them within your corporate firewall depending on your deployment scenario.

One major potential security issue is privilege escalation. Now, if you are using “more special” yet public-facing users in your public website to update content, you are one web.config typo away from opening up important sections of your admin tools to the general public. Whereas if you are working with separate applications, then such scenarios are not a risk. You can even use completely separate authentication methods with your admin tools, handy for corporate applications where people are used to Active Directory for authentication.

A final security advantage is at the database layer. Separate applications make it much cleaner and easier to use separate database accounts, allowing one to functionally separate the public permissions from the private permissions all the way down to the core. Meaning that even if something were to get horribly out of whack and a url-based Sql injection exploit make it into the wild, you could still breathe slightly easier knowing your public site’s database user is very, very locked down.

I would not advise taking this approach unless one has already adopted a solid 3-tiered design where the core business logic is embedded in a third assembly. Building websites this way using SqlDataSource is an exercise in folly. But, given a properly structured project, it has been quite a successful method for me.