Fortunately, I was able to get a little bit of satisfaction recently by NOT approving the following post:

Dear Russian Mafia, I didn’t approve this asshole’s comment.  You know what to do. 

For the rest of you all, I’ve turned on Captchas for commenting so at least the automated spambots will be kept out.  Sorry for the additional 10 seconds when posting comments here!

Countless essays, papers, statistical analyses, and blog posts have discussed the topic of passwords (a remarkably rich subject), so hopefully I’m not just adding to the the noise by saying: All too often, I see people forget about the “Threat Matrix” (not related to, well, anything by the same name).

The “threat matrix” is really a multi-dimensional graph of vulnerabilities, responses, and new vulnerabilities caused by those responses.  But for the sake of this post, let’s look at two of the dimensions:

1. In what ways can a password be circumvented, and
2. How can you counter those threats in the most effective way? 

A password can be beaten with a random string attack, dictionary attack, network sniffer, or simply a bad guy dropping by your office after-hours and rifling through your drawers.  A common mistake is thinking that common forms of thwarting some attacks necessarily make ALL attacks less likely.  Almost by definition, decreasing the odds of one attack type increase the odds of another. 

So, to the admins out there setting security policy: consider that the security benefits to increasing password length and complexity requirements do NOT rise linearly with increased length and complexity.  In fact, they drop off pretty quickly.

• A password that has a requirement of “10 characters, at least one lower-case and one upper-case, one number, one special character, and one ancient greek symbol that doesn’t appear on your keyboard” is NOT a more secure password.  Because, by the time the frustrated user has tried 47 different memorable-but-impossible-to-remember passwords, s/he’s gonna have to write that damned thing down – and we all know THAT isn’t secure.
• Full l33tspeak is not a secure password strategy.  If every one of your passwords is the l33tspeak version of the username (alidbuser/@l1dbu$3r, contentdb/c0nt3ntdb), it’s not secure.
• Dictionary attacks against a web site are impractical, and permanently locking accounts as a way to thwart them after 3 failed login attempts is ridiculous.  At very least, if you’re going to lock accounts, have them auto-unlock after 10 minutes.  This makes the effort to even try hundreds of passwords impractical, let alone the millions or billions that would be required for a full dictionary attack.

I think of all the blog posts I’ve written, this may have taken the longest.  I’ve written, re-written, and trimmed pages and pages of text to basically complain about amazingly complex password rules that some clients have in place without even knowing WHY (“because they’re more secure” is not the correct answer). 

As I’ve continually pruned this post so as not to completely bore you, I realize that the Threat Matrix is an important concept that all IT people should consider in all aspects of daily IT work.  There are plenty of real-world scenarios where the matrix of threats and responses are not fully understood, and hopefully we can make light of some of these in future posts.Only semi-related: I DARE you to ask me some time why I think some TSA agents have no idea of how to practically apply a Threat Matrix.  I’ll tell you the stor(ies) of when that TSA agent took my 2-oz toothpaste tube out of the shaving kit – which, incidentally, is neither a liquid, nor a gel, nor an aerosol – and put it in a quart-size plastic bag (to make sure it would fit?), then sent me on my way.  It’s a good thing most terrorists are dumber than most TSA agents:  I’m glad this guy never watched this.

HA! Truth is, while I’ve already done one lap around the “software utility” track, there are LOTs of Cool Tools out there – some directly related to portal development, debugging, or maintenance, and some more broadly defined.

In fact, I wouldn’t really consider today’s “Cool Tool” a “tool” at all – it’s a full-fledged application, and it’s likely to give the WebCenter stack a run for its money in the long term.

Allow me to introduce Atlassian’s Confluence – one of the web’s best Wiki platforms out there. We’ve been working with this application a lot lately, and have been very impressed with it. It’s a powerful wiki platform, has a robust third-party support and development network, is dramatically less expensive than Oracle products, and provides many of the features some clients bought the Plumtree portal for. (Does it surprise you to know that a bunch of the old Plumtree team ended up there?)

When ALUI Publisher was released, BEA occasionally said it would be the blog and wiki platform that customers had been waiting for (it wasn’t). Then, we started hearing that the ill-fated product called Pages was the REAL blog and wiki platform (it wasn’t). 2009 brought us some more “WCI Sample Portlets available for the Wiki/Blog/Discussions functionality” (meh, didn’t really work). This year the message clients have been hearing “it’s all about WebCenter Spaces”. Honestly, while we may or may not see the fabled 11g version of WebCenter Interaction, Spaces does look very intriguing. In my opinion, though, it’s still not as rich as the much more mature – some would say over-the-hill – WCI portal is now. And it certainly is not the right application for all WCI customers.

So, friends, until I see Oracle deliver the great, mythical, elusive Enterprise Wiki we’ve been hearing about for years, consider me firmly in the Atlassian camp on this one – the stability, ease of use, price-point, and sizable third-party ecosystem are first-rate! Don’t take my word for it – try it out yourself for ten bucks.

Stay tuned for many more tips and follow-up posts on Confluence and other third-party products that can work alongside your existing portal implementations – and some posts on where Confluence falls short of a “full Portal Replacement”. Until then, feast your eyes on… THIS:

OK I’m not going to lie to you, unlike most Cool Tools, it’s not easy to find a screen shot that embodies all of what a great wiki product Confluence is.  At least it’s not as hard as taking a picture of the wind…

Instead, let’s look at an alternate approach:  use the Collab Server as a sort of REST API.  It’s not really, but the basic idea is that you use URLs in your code to directly call functionality in Collaboration Server to do certain tasks.  For example, say you want to add a Collaboration project to a page programmatically; there is no mechanism to do this through the IDK, and we have no idea how to use the API, but using a header tool, we find that through Project Explorer, it works with a simple URL: /collab/do/project/selector/add?commPage=true&projID=COLLABID.

So, it turns out we can do the same thing programmatically, by using Java’s network libraries to call that URL directly (setting the proper authenticationid).  The code after the jump shows an example of how to do this; we use this approach in Integryst’s Automater, which allows you to script a bunch of actions at a time (what good is automatically creating a collab project if you can’t add it to a community page you just created!?). 

Tweak away!

int collabID = ParamHelper.getIntParamValue(getInputs(),"collabid",-1);
int communityID = ParamHelper.getIntParamValue(getInputs(),"communityid",-1);
String wsapi = ParamHelper.getParamValue(getInputs(),"wsapi");

String response = "";

LOG.info("> Add Collab Project to Community. Params [collabID=" + collabID + ", communityID=" + communityID + "]");

// the IDK doesn't provide methods for attaching messages to documents, so we use HTTP methods to do that
// collab settings for direct connection
String host = ParamHelper.getParamValue(getInputs(),"collab.host");
String port = ParamHelper.getParamValue(getInputs(),"collab.port");
String user = ParamHelper.getParamValue(getInputs(),"collab.user");
String pass= ParamHelper.getParamValue(getInputs(),"collab.pass");

// these may not be needed...
String imageserver = ParamHelper.getParamValue(getInputs(),"collab.imageserverurl");
String gadgetid = ParamHelper.getParamValue(getInputs(),"collab.gadgetid");
String pageid = ParamHelper.getParamValue(getInputs(),"collab.pageid");
String userid = ParamHelper.getParamValue(getInputs(),"collab.userid");
String username = ParamHelper.getParamValue(getInputs(),"collab.username");

String addr = "http://" + host + ":" + port + "/collab/do/project/selector/add?commPage=true&projID=" + collabID;

try{
LOG.debug("Attempting Collab Connection to " + addr);
URL url = new URL(addr);
HttpURLConnection conn = (HttpURLConnection) url.openConnection();
String encoding = new sun.misc.BASE64Encoder().encode((user + ":" + pass).getBytes());
conn.setRequestProperty ("Authorization", "Basic " + encoding);
conn.setRequestProperty ("CSP-Aggregation-Mode", "Multiple");
conn.setRequestProperty ("CSP-Activity-Rights", "uri%u003A%u002F%u002Furi%u002Ecollaboration %u002Eplumtree%u002Ecom%u002Factivity%u002Fviewpresence,uri%u003A%u002F %u002Furi%u002Ecollaboration %u002Eplumtree%u002Ecom %u002Factivity%u002Fbulkupload,uri%u003A %u002F%u002Furi%u002Ecollaboration%u002Eplumtree%u002Ecom%u002Factivity %u002Fmanagecollab,uri%u003A%u002F%u002Furi %u002Ecollaboration %u002Eplumtree%u002Ecom%u002Factivity %u002Fmanagecollabprojects");
conn.setRequestProperty ("CSP-Gateway-Specific-Config",
"PT-User-Name=" + username + "," +
"PT-User-ID=" + userid + "," +
"PT-Community-ID=" + communityID + "," +
"PT-Gadget-ID=" + gadgetid + "," +
"PT-Gateway-Version=2.5," +
"PT-Content-Mode=1," +
"PT-Time-Zone=America%u002FNew%u005FYork," +
"PT-Imageserver-URI=" + imageserver + "/," +
"PT-User-Charset=UTF-8," +
"PT-Page-ID=" + pageid + "," +
"PT-Community-ACL=15," +
"PT-SOAP-API-URI=" + wsapi + "," +
"PT-Class-ID=43," +
"PT-Guest-User=0");

conn.setRequestProperty ("USER-AGENT", "Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.2)");
conn.setRequestProperty ("CSP-Gateway-Type", "Plumtree");
conn.setRequestProperty ("CSP-User-Info", "FullName=" + username);
conn.setRequestProperty ("CSP-Protocol-Version", "1.3");
conn.setRequestProperty ("Accept-Language", "en-us");
conn.setRequestProperty ("CSP-Can-Set", "Gadget-User,User,Gadget-Realm,Realm");
conn.setRequestProperty ("Host", host + ":" + port);
conn.setRequestProperty ("ACCEPT", "*/*");
conn.setRequestProperty ("Accept-Encoding", "gzip");
conn.setRequestMethod("GET");

conn.connect();

// read the headers
for (int i=0; ; i++) {
String headerName = conn.getHeaderFieldKey(i);
String headerValue = conn.getHeaderField(i);

if (headerName == null && headerValue == null) {
// No more headers
break;
}
if (headerName == null)
LOG.debug("Response: " + headerValue);
else
LOG.debug("Response Header: " + headerName + ": " + headerValue);
}

InputStream in = conn.getInputStream();

// read the response
BufferedReader reader = new BufferedReader(new InputStreamReader(in));
String text = reader.readLine();
if (text != null)
LOG.debug("Response Text: " + text);

response += "Project " + collabID + " has been added to community : " + communityID + "
";

conn.disconnect();
}
catch(Exception ex) {
response = "Exception adding project " + collabID + " to community " + communityID + ": " + ex.getMessage();
LOG.error(response, ex);
}

addOutput(new Param("collabid", "" + collabID, "output", null));
addOutput(new Param("communityid", "" + communityID, "output", null));

LOG.info("< Add Collab Project to Community: " + response);
return response;
}

I’ve profiled header tools before (FireBug is an obvious one), but I haven’t profiled any IE header/debug tools yet.  I’ve used IEInspector’s HTTP Analyzer before, but for the love of all that was Holy and Mighty, that thing crashed IE more often than a WebCenter Consultant on a 24 hour code bender (didn’t see that one coming did you?  yeah, I’m not funny).

So, today’s profile is for my latest IE header tool of choice: IEWatch’s IEWatch Professional.  It’s not cheap at $169, but at least it’s not as bad as HTTP Analyzer and doesn’t fold like a cheap suit (yeah, i don’t even know what that means.  i’m not funny.).  The tool is straightforward:  install it and choose View: Explorer Bars: IEWatch from IE’s menu, and you’ve got a slick header tool that gives you a decent snapshot of what IE is doing behind the scenes, showing requests, responses, post data, and pretty much everything else you need to diagnose a poorly performing ALUI portal…

So here’s my question – given that HTTP Analyzer is cheaper, but has more bugs than this place (sheeeesh!  i TOLD YOU i wasn’t funny!), what IE header tool do YOU use?

One of these settings is the ALUI Automation Server: in “Select Utility: Automation Service”, you get a list of servers running the Automation Service, and can set which administrative folders are associated to which Job (aka Automation) Servers.  If you migrate the portal database between environments, you might have one entry show up for “PRODPORTAL3″ (in prod) and another for “PORTALDEV9″ (in dev).  But then in the dev environment you have to re-register every one of the folders that was associated with the prod folder. 

What if you could just create an alias that worked in both environments?  Fortunately, you can, and the tweak is easy:  Just edit %PT_HOME%\settings\configuration.xml in both environments, and change the value below to be the same thing.  Then, when the automation server in either environment starts up, it’ll look for jobs registered with that same name:

<component name="automation:server" type="http://www.plumtree.com/ config/component/types/automation">
<setting name="automation-server:server-name">
<value xsi:type="xsd:string">WCI-AUTOMATION</value>
</setting>

Oh, and if you’re a “UI” kind of person, you can achieve the same result by changing the name through the Configuration Manager:

So, today’s post is an easy one that answers the question: “which pages and communities are my portlets displayed on”?  The SQL is simple:

 select
                        ptcommunities.name community_name,
                        ptpages.name page_name,
                        ptgadgets.name portlet_name
from
                        ptcommunities,
                        ptpages,
                        ptpagegadgets,
                        ptgadgets
where
                        ptcommunities.folderid = ptpages.folderid
and                ptpagegadgets.gadgetid = ptgadgets.objectid
and                ptpages.objectid = ptpagegadgets.pageid

… and you’ll get a list of communities, pages and portlets that you can sort or filter any way you want:

If you’ve sweated through SQL*Plus sessions for way too long, definitely check this tool out – it’s cheap, at only $40.  If you’ve got a better tool for quick and easy Oracle DB queries, I’d love to hear about it in the comments!

I got lucky on this one, and hopefully if you found this post through a Google Search, you’ll have saved yourself the headache of trying to figure out what value should be in there.  The answer is in the Analytics Configuration Worksheet (PDF link):

That’s right: it’s “saml2keystore“.  Anyone know how to reset the actual value in Java’s Keystore for Analytics?

So, consider this a friendly reminder – especially if you’re exposing your portal on the Internet: stay vigalent, and take all threats seriously.  About 18 months ago, I got an alert in the middle of the night that we were out of drive space on a portal server at one of my semi-government clients.  No big deal; it happens all the time.  Only this time it was different.  Overnight, our logs had exploded from roughly 20MB/day to 2GB/day:  something was seriously wrong.  The logs were so big they were hard to even open, but when i did finally crack them open, here’s a snippet of what I found:

Basically, there were GIGABYTES of these requests – someone was scanning our servers, alternating in different object IDs for different spaces, looking for incorrectly secured communities or other portal objects.  They were basically just scanning different activity spaces, making all kinds of semi-random requests with different IDs a couple times a second.

It turned out that these particular baddies weren’t that sophisticated: they were making no effort to conceal their source IPs through some sort of distributed attack, and their algorithm clearly didn’t demonstrate a deep knowledge of how portal URLs are constructed.  And honestly, we were lucky for even finding this attack in the first place because at the time we didn’t regularly audit the logs, and only caught it because of that benign disk space warning.

In the end, we blocked the entire subnet (from China, a notorious hacker hangout), and the attacks stopped.  We should have reported the attempted breach, and I certainly would if it happened again, but I’m sharing this story with a single moral: no matter how “little” you think your site may be or how you think “noone cares about my little corner of the internet”, the bad guys are out there, and they don’t discriminate when they’re looking for victims.

So, take a minute today to check your security settings one more time, and keep an eye on those log files for anything suspicious!