This entry is about Web Content Management (WCM) content security (potentially delivered through a Portal) and does not refer to Digital Rights Management (DRM), although I can see this discussion being extended to discuss DRM as well.

When you talk about securing content in WCM world, it could fall under two main categories, content security and content personalization. It could be surprising to see personalization being talked under the security, but some people still blur the difference between two. Here is my definition to differentiate the two; security, when you should not have access to content if it is not meant for your consumption, personalization, when you don’t see the content on your landing pages, but you can access it through some other means.

Any WCM/Portal application designed to provide this feature has to deal with performance of application, as each user is accessing the pages with different combination of security (groups , roles or profile attributes) resulting in different queries to generate the page Vs. each user accessing the same page generated through one query. If the combination of security attributes is small, overall number of queries for all pages would remain in vicinity of non-secured content pages. But, when you talk about thousands (or millions) of end-users hitting the site resulting in millions of page-views, you would have to think about how much hardware you are ready to use for your site that deliver content security and/or personalization. More combinations you use, chances are high you would end-up using more hardware.

Most WCM/Portal solutions have some kind of caching mechanism to reduce the impact on back-end, but they work efficiently when overall cache-hit is high (cache-hit: same page is accessed by multiple users, so only first user hit would create an impact on back-end, rest access would result in serving the content from the cache). In case of content security and/or personalization, these cache hits are reduced, creating an impact on your back-end systems.

In the end, it boils to down to balancing the two, how much functionality you would provide to end user for content security/personalization Vs. how much you would like to spend for delivering that content through your infrastructure. It is not an easy decision, as we move towards more personalized web, every consumer of your site is expecting this feature, at the same time, the relentless cycle of extracting more out of less puts high pressure on delivering this functionality with limited infrastructure.

If you are in a similar position, you could try to limit the scope of personalization/security to certain pages (you would have to analyze overall use-cases to come up with recommendations) or use an intelligent caching solution (either part of WCM/Portal, or built on top of it). This functionality will make more impact on your infrastructure than non-personalized content, although you can limit the impact through judicious business requirements and/or technical design.

We are living in a new world where if we want people to get excited about an idea/concept, we give it a version number. We started with Web 2.0 and now we are discussing Enterprise 2.0, and some of our cutting edge technologists are already discussing what feature would be part of Web 3.0! I am not in complete agreement about the versioning numbers, as Web is something that has been around for less than 20 years, but enterprises have been around for 100’s of years and to put everything till now as 1.0 is not doing it justice (I know, I know, you need to start somewhere, but we could have started with Enterprise 9.0 as well).

I was reading about Enterprise 2.0 conference and came across their definition of Enterprise 2.0, it seems pretty good, but I felt one of the main statement of this definition can cause confusion on what Enterprise 2.0 stands for, this is the part of definition that could be confusing “Enterprise 2.0 is the term for the technologies and business practices that liberate the workforce from the constraints of legacy communication and productivity tools like email.”

At first, I didn’t understood why email is a bad productivity tool? I am a Blackberry junkie and my work life depends on email, so how come it is bad? As I thought about it, I understood this is trying to explain (among other things) that legacy way to communicate information in a top/down manner is Enterprise 1.0 and now your email consumers would like to see this communication in a way that your consumers have choice of reading or participating in conversation, not just with you but people like them are reading it. This also brings them to your web-site and keeps them engaged, where you can tell/sell them more!

This does not take the email away, it is still useful for communication with one person or a small group, but as your group size gets bigger and communication is/was more formal, Enterprise 2.0 has tools for you to make this communication effective (hint - it is called Blog in Web 2.0).

When I first learned about IT security in Internet world, I was told to assume “that some hacker is already in DMZ” before I architect any security framework. It helped me tremendously, whenever I was involved in web-sites security projects or related discussions. I was also aware of direct hacks from the browser, if your application is not written with security in mind. I did not realize how fast this field of “browser hacks” have grown.

While reading a blog entry from John Conroy of CMSWire (How They Hack Your Website: Overview of Common Techniques), it was quite tempting to try some of the hacking options and see if your preferred sites breaks (I tried and could not break it, I am happy about it!). There were good points in the comments by Jason and others to round up the blog with overall perspective.

What jumped out to me from the blog was that how vulnerable web-sites have become that a simple slip can cause a much bigger problem (Harvard Site Hacked, Alleged Content Hits BitTorrent). Of course, with packaged application (as most ECM products are) it is difficult to achieve complete control of code and how it executes different components. So, one of the due diligence you own is asking the Vendors about their application’s design from security perspective that thwarts “browser hacks”. It could also occur when you lack a trained team, who should not only understand the basics of web-sites management, but also design application to be secured at all levels (not just protocol, code and configuration as well).

In this world of highly interactive web applications, it is very easy to put lot of logic in browser to make interactions easy and closer to end-user, but this can open up new pathways to hack into your application, if you do not take appropriate steps to block it. Now, if I am participating in any security discussions, rather then mentioning my old advice “someone in the DMZ”, I say “someone has crossed DMZ and is trying to manipulate your application”.

I came across Tony White’s blog recently and his post “WCM and Portal” by Any Other Name, Still “WCM and Portal” caught my attention. I have run into this problem more than few times, where a customer would be stuck on not using “Portal” for their solution, although this product whose name ends in “Portal” satisfies their requirement, along with rest of the proposed solution (e.g. WCM + Portal is the solution). They would vehemently oppose any use of portal for that particular solution or may have a corporate portal which they can use, but is not the right fit for the solution.

On other hand, I have run into customers who want to use “Portal” for their solution, irrespective of whether that is a right fit or not. For instance, customers may want to control layout from WCM and do not have many requirements on personalization, still would like to use portal and then would like to customize everything about that portal to meet their needs.

To be fair, there are valid instances where a new portal or WCM would make customer’s environment more complicated and managing it from IT perspective would take more resources. On other hand, if existing Portal/WCM do not satisfy customer’s requirements and they try to fit new WCM/Portal to this mix, it would create bigger issues on managing the customizations that would have to be developed to meet the requirements. This is where Tony’s suggestion on looking at solution from requirement perspective is the safe approach, as you can weigh different set of product capabilities equally.

Name of the product and its categorization still carries a lot of weight while choosing a solution. I have seen ECM vendors trying to sell their “Portal” as “Presentation Engine” with advanced features, so they do not get dragged into the “Name” fight. Can we still say, what’s in the name?

I was surprised to see this topic for an upcoming event in NYC hosted by ISF and SIM (Feb 26, 2008). Surprised, not shocked, as I have seen enough customers to know the sentiment, and I believe that there is some truth to it.

CMS promises to be ultimate in flexibility, and it does not lives up to it all the time. Rather than accepting the limitations, many customers end up walking on heavy customization path and then find themselves in a position where base product cannot be customized any further. Now, they have invested a lot of time and money, and they still don’t have what they wanted and so the sentiment comes out, “I hate my CMS”!

I think we have to start accepting that there is no magic-bullet when it comes to CMS and CMS do have limitations. If we understand its limitations and see that we choose right platform for our current and future needs, with focus on reducing customizations, you could have a winner.