Oracle Announces Roadmap for Plumtree / AquaLogic / WebCenter

UPDATE 2: I’ve incorporated all the great feedback and comments from ex-Plumtreevians, ex-BEA and ex- and current Oracle folks.

UPDATE: A bunch of Plumtreevians are contributing really good comments on this post over on Facebook.

bea_think_oracleI worked at Plumtree Software, Inc. from June 1998 to December, 9th 2002. In four-and-a-half years, the company grew from 25 employees to over 400 and it had thousands of happy customers before it was purchased by BEA Systems in 2005 for $220M. Here at bdg, we’ve been supporting dozens of Plumtree/AquaLogic Interaction (ALI)/WebCenter Interaction (WCI) customers since we opened our doors in December of 2002.

Back around 2005, BEA’s BID (Business Interaction Division) still had a lot of really smart engineers from Plumtree working on a lot of really interesting things, including Pages (think CMS 2.0), Pathways (kind of an enterprise version of del.icio.us) and Ensemble (the portlet engine/gateway, minus the overhead and UI of the portal itself).

They were also working on an enterprise social network, kind of a Facebook for business if you will.

However, there was a lot of wrangling at BEA, primarily between BID/AquaLogic and BEA’s flagship product, WebLogic (the world-class application server). Most of the strife came in the form of WebLogic Portal vs. AquaLogic/Plumtree Portal nonsense. Senior management at BEA, in their infinite wisdom, had taken a “let’s try not to alienate any customers” policy and in the process they confused all their customers and alienated/frustrated quite a few of them as well. They renamed Plumtree to AquaLogic User Interaction (ALUI), put in place a “separate but equal” policy with WebLogic Portal (WLP) and spewed some nonsense about how WLP was for “transactional portal deployments” vs. ALI for .NET and non-transactional portals, but no one, including BEA management, had any idea WTF that meant. To further confuse the issue, the WLP team, which also had a lot of really smart engineers, built products like “Adrenaline” (which was basically a less-functional and more buggy version of Ensemble) rather than do the unthinkable and integrate Ensemble into WLP so that WLP could finally host non-Java/JSR-168 portlets.

I was really pissed about BEA’s spineless portal strategy, their “separate but equal” policy between WLP and BID/ALUI and their waste of precious engineering resources in an arms race between WLP and ALUI rather than just stepping back, growing a spine, and coming up with a portal strategy.

Because I can’t keep my pie hole shut, I started several loud, messy and public fights with BEA management. Why? Because the real loser here is the customer.

And BEA, because management got mired in politics and chose to waste engineers’ time on in-fighting and competition instead of building enterprise Facebook, which Steve Hamrick and I arguably already wrote in our spare time. All they needed to do was product-ize that and they would have owned that market.

In 2008, Oracle inherited this clusterfuck of a portal strategy when they bought BEA for $7B+, giving me new hope that cooler heads would prevail and fix this mess. The first thing they did was fire all the impotent BEA managers who were afraid to make any decisions. It took Oracle a while, but alas, they have finally arrived at a portal strategy that makes sense. I first learned about this strategy when I crashed the WebCenter Customer Advisory Board last Thursday.

First of all, let me say this: under the leadership of Vince Casarez, current (and future) customers are in good hands.

I realized when he said “everyone still calls it Plumtree” that this was going to be a bullshit-free presentation.

He also said something regarding the “portal stew” at Oracle that puts all of my ranting and raving in perspective: “Oracle did not buy BEA for Plumtree or WLP, just like it didn’t buy SUN for SUN’s portal product.” To rephrase that, Oracle bought BEA for WebLogic (the application server, not the portal) and Sun for their hardware (not for Java, NetBeans and all the rest of Sun’s baggage).

So, let’s face it, portals are a relatively insignificant part of Oracle.

However, they’ve finally did what I called for 2008 and what BEA never had the wits to do: pick a single portal strategy/stack and stick to it. SO, if you’re a current Plumtree/ALUI/WCI or a current WLP customer, you have a future with Oracle.

Here’s the plan, as I understand it.

All roads lead to Web Center (not Web Center Interaction, but Web Center)

At the heart of Web Center will be WebLogic’s app server and portal. Plumtree/ALUI as a code base will be supported, but eventually put into maintenance mode and retired. You get nine or twelve years of support and patches (blah blah blah) but if you want new features, you need to switch to the new Web Center, powered by WLP. CORRECTION: WebCenter will not be “powered by WLP.” At its core will be the Oracle-developed, ADF-based WebCenter Portal running on WebLogic Server.

All the “server products” (Collaboration, Studio, Analytics, Publisher) will be replaced by Web Center Services or Web Center Suite

Publisher will be subsumed by WCM/UCM (Web Content Management / Universal Content Management, formerly Stellent). The other products will be more-or-less covered by similar offerings in Suite or Services.

What about Pages, Ensemble and Pathways?

Pages is dead as WCM/UCM does it better. Pathways is getting rolled into the new Web Center somehow, but I’m not sure how yet. Perhaps I can follow up with another blog post on that. Ensemble has been renamed “Pagelet Producer” — more on that below. CORRECTION: Pathways is now called “Activity Graph” and it will be part of the new WebCenter. Think of an enterprise-class version of the Facebook News Feed crossed with Sales Force chatter and you’ll be on the right track.

What about .NET/SQL Server, IIS and everything else that isn’t Java?

This is a really interesting question and the key question that I think drove a lot of BEA’s failure to make any decision about portal strategy from 2005-2008. Plumtree had a lot of .NET customers and some of the biggest remaining Plumtree/ALUI customers are still running on an all-Microsoft stack. In fact, one of them told me recently that they have half a million named user accounts, two million documents and 72 Windows NT Servers to power their portal deployment.

So, let’s start with the bad news: Oracle doesn’t want you to run .NET/Windows and they REALLY don’t want you to run on SQL Server.

(That will change when Oracle acquires Microsoft, but that’s not gonna happen, at least not any time soon.) WebLogic app server and WLP/WCI, to the best of my knowledge, will not run on SQL Server. They will, however, run on Windows, but I would not recommend that approach.

It’s inevitable that large enterprises will have both .NET and Java systems along with a smattering of other platforms.

So, if you’re a .NET-heavy shop, you’ll need to bite the bullet and have at least one server running JRockit or Sun’s JVM, one of Oracle’s DB’s (Oracle proper or MySQL), WLS/WLP/WCI and preferably Oracle Enterprise Linux, Solaris or some other other flavor of Un*x. CORRECTION: WLP will run on SQL Server. Not sure about the new WebCenter Portal, but my guess is that it does not.

Now, for the good news: the new WCI, powered by WLP and in conjunction with the Pagelet Producer (formerly Ensemble) and the WSRP Producer (formerly the .NET Application Accelerator) will run any and all of your existing portlets, regardless of language or platform.

This was arguably the best feature in Plumtree and it will live on at Oracle.

.NET/WRSP and even MOSS (Sharepoint) Web Parts will run in WebCenter through the WSRP Producer. The Pagelet Producer will run portlets written in ANY language through what is essentially a next generation, backwards-compatible CSP (Content Server Protocol, the superset of HTTP that allows you to get/set preferences, etc. in Plumtree portlets). So, in theory, if you’re still writing your portlets in ASP 1.0 using CSP 1.0 and GSServices.dll, they will run in the new Web Center via the Pagelet Producer. Time for us to update the PHP and Ruby/Rails IDKs? Indeed it is. Let me know if you need that sooner rather than later.

How do I upgrade to the new WebCenter?

Well, first off, you have to wait for it to come out later this fall. Then, you have to start planning for what’s less of an upgrade and more of a migration. Oracle, between engineering and PSO, has promised to provide migration for all the portal metadata (users, communities, pages, portlets, security, etc.) from Plumtree/ALUI/WCI to the new Web Center, with WLP at its heart. (Wouldn’t it have made sense for some of those WLP engineers to start building that migration script in 2005 instead of trying to compete with ALUI by building Adrenaline? Absolutely.) All your Java portlets, if you’re using JSR-168 or JSR-286, will run natively in WLP through a wrapper in WebCenter Portal. Everything else will either run in the WRSP Producer (if it’s .NET) or in the Pagelet Producer (if it’s anything else). The only thing I don’t fully understand yet is how to migrate from Publisher to UCM, but I’m due to speak with Oracle’s PSO about that soon. Please contact me directly if you need to do a migration from Publisher to WCM/UCM that’s too big to do by hand.

The only other unanswered question in my mind is how the new WebCenter will handle AWS/PWS services — the integrations that bring LDAP/AD users and profile information/metadata into Plumtree/ALUI/WCI. I wrote a lot of that code for Plumtree anyway, so if Oracle’s not working on a solution for the new Web Center, perhaps I can help you with that somehow as well. CORRECTION: User and group objects are fully externalized in Web Center, so there is no need for AWS/PWS synchronization. (Thanks, Vince, for pointing that out.)

So, that’s my understanding of the new portal strategy at Oracle.

Kudos to Oracle’s management for listening to their customers, making some really hard decisions and picking a path that I think is smart and achievable.

I’m here to help if you have questions or need help with your portal strategy or technical implementation/migration.

Q&A;

(Some other notes about discussions that have spawned from this original post.)

Q: What’s the future of the Microsoft Exchange portlets (Mail, Calendar and Contacts) and the CWS for crawling Exchange public folders. Retired and replaced with something Beehive related? Still supported? For how long? Against what versions of Exchange?

A: We’ve got updated portlets for Mail & Calendar in WebCenter now for Exchange 2003 & 2007. We don’t have a Contacts portlet but it could be added quickly if we see a large demand. Crawling public folders can be done with an adapter we have for SES [Oracle Secure Enterprise Search] already. We’re working but aren’t done with a new version of KD on top of the new infrastructure that will come out post PS3. (Contributed by Vince Casarez.)

Q: If migration scripts are provided to move WCI metadata into WebCenter, I understand that a portlet is a portlet, but what about pages and communities, users and groups, content sources and crawlers, etc.? Do they all have analogous objects in WebCenter or is there some reasonable mapping to some other objects?

A: Pages and Communities follow a model where we extract/export the meta data and data, then run it through a set of scripts that create a WebCenter Space for each Collab project/community and a JSPx page for every page. Users and Groups will come out of the LDAP/AD directory they are already using and the scripts associate the right permissions to each of the migrated objects. I don’t recall what we did about crawlers but since we use SES directly, all the hundred or more connectors we ship for SES are now available for direct usage. The scripts go through a multiphase approach to move content, then portlets, then pages, then communities so that dependencies can be fixed up versus trying to do a manual fix up. (Contributed by Vince Casarez.)

Q: Will any existing WCI-related products that are slated for retirement (e.g. Publisher, Collab, Studio, Analytics, etc.) be re-released with support for Windows Vista, Windows 7, IE 8, IE 9 or Chrome?

A: For Publisher, we are planning a set of migrations to quickly move them to UCM. For Collab & Studio, we have new capabilities in WebCenter Spaces to match these functions. For Analytics, we’ve also rebuilt it on top of the WebCenter stack with over 50 portlets for the different metrics and made sure we provide apis/ access to the data directly. These analytics data also feeds the activity graph in providing recommendations for people on the content and UIs that are relevant to them. These are tied into the personalization engine that we brought over from the WLP side. So there is a rich blending of the best features from WLP with WCI key features. As for Neo [the codename for the next release of WCI], we are certifying the additional platforms. On the IE 8 front, we’ve just released patches for WCI 10gR3 customers to be able to use IE8 without upgrading to Neo. (Contributed by Vince Casarez.)

Upcoming Oracle Web Center Interaction Training

Just wanted to let you know that I (formerly Plumtree’s Lead Engineer, worked with hundreds of different Plumtree, BEA and Oracle customers and now an Oracle ACE Director) am leading a public training course over the next two weeks and if you’re interested, there are few available slots left.

We’re partnering with training provider Peak Solutions and you can find the full details on their web site. Here’s the critical information:

THIS Monday, May 3rd and Tuesday, May 4th in Harrisburg, PA
Oracle WebCenter Interaction Administration – $1,200
Deployment planning, installation, configuration, maintenance, troubleshooting, etc.

NEXT Monday, May 10th, 11th and 12th in Harrisburg, PA
Oracle WebCenter Interaction Portlet Develoment in Java and .NET (also Ruby and PHP) – $1,800
Hello world all the way through advanced portlet dev concepts like setting preferences and using caching

Please drop us a note if you’d like to attend. There are only 4-5 slots left, so please act now to reserve your space!

Write an ALUI IDS in Under 15 Lines Using Ruby on Rails

Not only is it possible to write an ALUI Identity Service in Ruby on Rails, it’s remarkably easy. I was able to do the entire authentication part in fewer than 15 lines of code! However, I ran into problems on the synchronization side and ended up writing that part in Java. Read on for all the gory details.

As part of building the suite of social applications for BEA Participate 2008, we’re designing a social application framework in Ruby on Rails and integrating it with ALI 6.5. Not being a big fan of LDAP, I decided to put the users of the social application framework in the database (which is MySQL). Now, when we integrate with ALI, we need to sync this user repository (just as many enterprises do with Active Directory or LDAP).

So I set out to build an IDS to pull in users, groups and memberships in Ruby on Rails.

It’s pretty obvious that Ruby on Rails favors REST over SOAP for their web service support. However, they still support SOAP for interoperability and it mostly works. I did have to make one patch to Ruby’s core XML processing libraries to get things humming along. I haven’t submitted the patch back to Ruby yet, but at some point I will. Basically, the problem was that the parser didn’t recognize the UTF-8 encoding if it was enclosed in quotes (“UTF-8”). This patch suggestion guided me in the right direction, but I ended up doing something a little different because the suggested patch didn’t work.

I changed line 27 of lib/ruby/1.8/rexml/encoding.rb as follows:

 enc = enc.nil? ? nil : enc.upcase.gsub('"','') #that's a double quote inside single quotes

Now that Ruby’s XML parser recognized UTF-8 as a valid format, it decided that it didn’t support UTF-8! To work around this, I installed iconv, which is available for Windows and *nix and works seamlessly with Ruby. In fact, after installation, all the XML parsing issues went bye-bye.

Now, on to the IDS code. From your rails project, type:

ruby script/generate web_service Authenticate

This creates app/apis/authenticate_api.rb. In that file, place the following lines of code:

class AuthenticateApi < ActionWebService::API::Base
 api_method :Authenticate, :expects => [{:Username =>
:string}, {:Password =>
:string}, {:NameValuePairs =>
[:string]}], :returns =>
[:string]
end

All you’re doing here is extending ActionWebService and declaring the input/output params for your web service. Now type the following command:

ruby script/generate controller Authenticate

This creates the controller, where, if you stick with direct dispatching (which I recommend), you’ll be doing all the heavy lifting. (And there isn’t much.) This file should contain the following:

class AuthenticateController < ApplicationController
 web_service_dispatching_mode :direct
 wsdl_service_name 'Authenticate'
 web_service_scaffold :invoke

 def Authenticate(username, password, nameValuePairs)
   if User.authenticate(username, password)
     return ""
   else
     raise "-102" #generic username/password failure code
   end
 end
end

Replace User.authenticate with whatever mechanism you’re using to authenticate your users. (I’m using the login_generator gem.) That’s all there is to it! Just point your AWS to http://localhost:3000/authenticate/api and you’re off to the races.

Now, if you want to do some functional testing (independently of the portal), rails sets up a nice web service scaffold UI to let you invoke your web service and examine the result. Just visit http://localhost:3000/authenticate/invoke to see all of that tasty goodness.

There you have it — a Ruby on Rails-based IDS for ALUI in fewer than 15 lines of code!

The synchronization side of the IDS was almost just as simple to write, but after countless hours of debugging, I gave up on it and re-wrote it in Java using the supported ALUI IDK. Although I never could quite put my finger on it, it seemed the problem had something to do with some subtleties about how BEA’s XML parser was handing UTF-8 newlines. I’ll post the code here just in case anyone has an interest in trying to get it to work. Caveat: this code is untested and currently it fails on the call to GetGroups because of the aforementioned problems.

In app/apis/synchronize_api.rb:

class SynchronizeApi < ActionWebService::API::Base
 api_method :Initialize, :expects =>
[{:NameValuePairs =>
[:string]}], :returns =>
[:integer]
 api_method :GetGroups, :returns =>
[[:string]]
 api_method :GetUsers, :returns =>
[[:string]]
 api_method :GetMembers, :expects =>
[{:GroupID => :string}], :returns =>
[[:string]]
 api_method :Shutdown
end

In app/controllers/synchronize_controller.rb:

class SynchronizeController < ApplicationController
  web_service_dispatching_mode :direct
  wsdl_service_name 'Synchronize'
  web_service_scaffold :invoke

  def Initialize(nameValuePairs)
    session['initialized'] = true
    return 2
  end

  def GetGroups()
    if session['initialized']
      session['initialized'] = false
      groups = Group.find_all
      
      groupNames = Array.new
      for group in groups
        groupNames << "<SecureObject Name=\"#{group.name}\" AuthName=\"#{group.name}\" UniqueName=\"#{group.id}\"/>" 
      end 
      return groupNames
    else
      return nil
    end
  end
  
  def GetUsers()
    if session['initialized']
      session['initialized'] = false
      users = User.find_all
      
      userNames = Array.new
      for user in users
        userNames << "<SecureObject Name=\"#{user.login}\" AuthName=\"#{user.login}\" UniqueName=\"#{user.id}\"/>" 
      end
      
      return userNames
    else
      return nil
    end
  end

  def Shutdown()
    return nil
  end
end

Comments

Comments are listed in date ascending order (oldest first)

  • Nice post, Chris. This is the first time I’ve seen this done!

    Posted by: dmeyer on January 20, 2008 at 4:16 PM

  • Thank you, David.I just noticed that part of my sync code was chomped off in the blog post because WordPress was assuming that was actually an opening HTML/XML tag. I made the correction so the above code now accurately reflects what I was testing.

    Posted by: bucchere on January 21, 2008 at 1:16 PM

One Portal to Rule Them All

I won’t rehash what’s already been said by everyone in the press and the blogosphere — Oracle is buying BEA. I wrote almost three years ago that this was inevitable, and now it’s upon us.

I’m hopeful that the BEA/Oracle management crew can take what they learned from the Plumtree, Fuego and Flashline (for BEA) and Siebel, PeopleSoft and Oblix (for Oracle) acquisitions and apply it to the challenges their own merger presents.

Over the past three years, Oracle has acquired dozens of companies. The most notable were probably PeopleSoft (which had just acquired JD Edwards, if I remember correctly), Siebel and Oblix, which gave them a great suite of HR apps, CRM apps and identity management, respectively. These were all enterprise software products that Oracle had, with a modicum of success, built on their own from the ground up, sold and supported as “Oracle Apps.”

Of course, with almost every major company they’ve acquired, Oracle has picked up a portal product. (And with BEA, there’s a special bonus — they get two: WLP and ALI.)

That’s going to create a portal soup consisting of at least the following ingredients:

  • Siebel Portal
  • JD Edwards Portal
  • PeopleSoft Portal
  • Oracle Portal (part of Oracle Fusion Middleware)
  • WLP
  • ALI

Oracle won’t want to endanger existing customer relationships by terminating support for the non-horizontal portals from Siebel, PeopleSoft, etc. Besides, the word “portal” really only loosely applies there, because those “portals” are really just web UIs into Siebel, PeopleSoft, etc.

But what about the horizontal portals: Oracle, WLP and ALI?

They are all playing in the same space. It’s already questionable that we need all three in the market now. And three under the same circle-shaped roof that is Oracle? Absurd.

What will Oracle do with this portal quandary?

Well, I think they’ll do the only thing they can do and support all the products. So that covers legacy customers, but what about future customers? If I’m an Oracle sales rep and my customer wants to buy a portal to front their SOA stack, what on earth do I sell them?

In my opinion, which is just that — my opinion — post-merger, there need to be some decisive acts from Oracle regarding the future direction of their portal strategy.

And, again, IMO, this is where the ALI portal and the ALUI suite of products (formerly Plumtree) can really shine. Why? Because not only can you front Java, .NET, Rails, PHP and any other web application stack with ALI, but ALI already has integration kits for Siebel, PeopleSoft, JSR-168, WSRP and five different flavors of SSO, including Oblix! (Not to mention the obvious fact that since day one, ALI has run beautifully on Windows and *nix systems using Oracle’s bread-and-butter product, their database.) So naturally, if you’re an Oracle shop running a clustered Oracle DB for storage, Siebel for CRM, PeopelSoft for HR, Oracle Financials for the books and Oblix Identity Management, no other product under the sun has more pre-packaged, no-brainer integration and integration options than ALI.

It may be a hard, bloody battle to get Oracle to drop it’s own beloved portal product in favor of AquaLogic Interaction, but I think it’s a battle that needs to be fought.

Same goes for WLP. In fact, I think every product acquired by Oracle has to fight for it’s life and fight to be the #1 product in the space, retiring the others to “maintenance and support” but focusing all futures on the product that is rightfully #1. And I think — and hope — that Oracle has the good sense and the wherewithal to encourage this.

It may cause some near term pain, but taking a longer-term view it’s the right thing to do.

Comments

Comments are listed in date ascending order (oldest first)

  • Interesting post, Chris. Obviously this is something we ALUI consultants have been considering in the past few days. One monkeywrench I have for you: as far as I know, Oracle offers their portal product for free to existing customers, whereas we (obviously) charge for it. I wonder how that kind of business model might change the landscape of how the ALUI portal is distributed/used.

    Posted by: rbrodbec on January 18, 2008 at 7:02 AM

  • Funny you should mention the price issue. About two years ago, we had a customer switch from ALI to Oracle portal for that exact reason. Why pay for licenses and support for ALUI products when Oracle gives you the portal for free? That customer still calls on us for ALUI support, so apparently the migration hasn’t gone exactly as planned.Two old adages come to mind here:
    1. You get what you pay for.
    2. There’s no such thing as a free lunch.

    Regarding #1, the products really don’t cover the same feature set — Oracle portal cannot be the gateway to SOA that we all know ALUI is, so it’s really not an apples-to-apples comparison.

    Regarding #2, with any free software, whether it’s from a large company like Oracle or from the Apache Software Foundation, you always need to think about Total Cost of Ownership (TCO). If you need to build services integration points in Oracle Portal to talk to all of Oracle’s other products, that adds to your TCO. Moreover, if somebody is giving something away, what sort of quality expectations do you have about the product? What happens if you need to request support from Oracle or ask them to develop a patch for you? All of a sudden, the fact that you didn’t pay for the software comes back and bites you in the butt. 🙂

    Posted by: bucchere on January 18, 2008 at 7:23 AM

  • I guess I agree with you, since I’m not an Oracle portal consultant (not yet, anyway); but I think the bigger question is how Oracle will assimilate these new portals given its current pricing strategy (aka – the bloody war you speak of). If I were an existing Oracle customer, the first question I’d ask is “how come I can get XYZ portal for free but not ABC portal”. And if I’m Oracle product management, I’m thinking about how my current “free portal” strategy has been working out for me versus the ALUI model of charging for it.

    Posted by: rbrodbec on January 18, 2008 at 8:22 AM

  • You’re right — the big issue is how will Oracle deal with the portals they’re acquiring and will there be a shakedown or more of a graceful assimilation.There’s a similar issue with WLS and Oracle’s application server, although I think in that case the answer is a little less complicated. 😉

    Posted by: bucchere on January 18, 2008 at 8:32 AM

  • Of course you completely forgot to mention Oracle WebCenter. In spite of your assertions, there are only 2 portal products at Oracle. Oracle Portal and WebCenter. WebCenter is the future “face” of Fusion Applications, so any integration of portal products will move in that direction. IMHO….plumtree is as proprietary as Oracle Portal, and its dead. WLP and the folks on the WebCenter team will need to figure out how to integrate the code bases of those two products since they are the most similar in their support of Web 2.0 futures.

    Posted by: Dr. BEA Good on January 20, 2008 at 11:44 AM

  • Thanks for the correction about Oracle WebCenter — I’m not too familiar with Oracle products other than the DB and I should have done more homework before posting this!However, I still disagree that there are only two portals at Oracle. I’m not too sure about JDE, but I remember with 100% certainty that PeopleSoft and Siebel called their UIs “portals.” They’re not truly portals in a horizontal sense like Oracle Portal, WebCenter, WLP and ALUI and I don’t think they’re actually relevant to this discussion, so it’s a moot point.

    Now, given the four remaining portal products, I challenge your assertion that WebCenter and WLP “support Web 2.0 futures” and I’d like to see some examples that support that claim. As far as I know, the only products coming out of BEA that deserve the “Web 2.0” label are AquaLogic Pages, Ensemble and Pathways. (Note I don’t include ALI itself as a Web 2.0 product, despite the fact that ALI 6.5 has some pretty slick social features that might someday earn it that distinction.)

    I also take issue with your calling Plumtree/ALUI proprietary and I’m not sure what makes you make that claim. It’s written in Java and ported to C#.net, so it runs “natively” on IIS (which no other products from BEA or Oracle can do). Its Java version (from the same source base), runs on WebSphere, WLS, Tomcat and probably JBoss and other app servers and it supports both Oracle and SQL Server, so in terms of how and where you can run it, it’s probably the most open and flexible product in the entire 40+ product lineup that BEA boasts.

    That’s just one side of the proprietary vs. open argument. The other is how well one supports standards for plugging in functionality. In those terms, I think ALUI stands out from the pack as well. It supports portlets over two very well supported standards: HTTP and HTML, which again makes it the most flexible portlet development environment on the market. (You can develop ALI portlets using ANY web server that speaks HTTP and I’ve personally done so using Java, .NET, LAMP, Ruby on Rails, Groovy on Grails and even Domino if you can believe that.) It also supports JSR-168 and WSRP. (In reading about WebCenter, all portlet development documentation was Java-centric, so I’m not sure if they support any other kind of portlet development, e.g. .NET. It’s crucial that any product which claims to be the “face of SOA” supports at least Java and .NET development and plugins; however, many would argue that you need to support much more — e.g. Ruby on Rails, PHP, etc.)

    Leaving portlets out of the picture for a moment, consider the other ALUI integration points: AWS, PWS, CWS and SWS. All of them use SOAP, which is a documented open standard. In fact, in my next blog post (which went up last night), I talk about how I integrated a custom MySQL/Ruby on Rails user store with ALI using a Rails-based SOAP-driven web service to interface with ALI’s user management system. It just doesn’t get any more open than that. At last year’s Participate conference, I demonstrated how you could use the ALI “face” to front WLS applications written to run on the WL message bus and communicating with data stores using DSP, proving that you integrate ALUI products with pretty much anything. I would like to see how a WebCenter consultant or a WLS guy would approach integrating Siebel or PeopleSoft, two products now in the Oracle family.

    I may make many “assertions” (as you call them), but they’re backed up by solid facts. I’m open to continuing this dialog because I want to hear more facts about 1) how you perceive ALUI as a proprietary technology and 2) how WLP and WebCenter claim to support “Web 2.0.”

    Posted by: bucchere on January 20, 2008 at 6:10 PM

  • Out of respect of SEC rules, I won’t touch the Oracle topic. But as for WebLogic Portal (WLP)…2) how WLP … claim to support “Web 2.0.”There are a bunch of features that contribute to the overall Web 2.0 story for WLP. Look at the WLP Groupspace application, for example. Web 2.0 is about publishing social applications that get better the more people use them. Groupspace is such an app. It is first a packaged social app ready to go out of the box, but secondly shows off many of the WLP features in the area of “Web 2.0”.

    Groupspace doc link (community framework, RSS, Groupnotes (think wiki), discussion forums, shared document repository, calendar, contacts, etc, etc).

    Also, read up on Josh Lannin’s blog to see what will be out shortly in terms of WLP and REST, more Ajax, more Portlet Publishing (Google Gadgets, RoR, PHP, etc). Lannin’s WLP futures

    Cheers – PJL

    Posted by: plaird on January 21, 2008 at 8:30 PM

Upcoming AquaLogic Training Classes in DC

bdg is hosting an AquaLogic (Plumtree) Training Class in Washington, DC the week of September 24th.

We’ll be sticking with the format we used last time:

Monday, Tuesday and Wednesday: ALI Administration
Wednesday, Thursday and Friday: ALI Portlet Development

Wednesday will be a “double up” day when we do advanced administration for admins and introductory administration for developers.

Training will run 9AM-5PM each day with a break for lunch. The location will be as follows:

Nextec Corporate Headquarters
465 Herndon Parkway, Suite 200
Herndon, VA 20170

ALI Administration (Mon, Tues, Wed)

This course provides a comprehensive overview of all the most commonly used aspects of AquaLogic Interaction (ALI). Students will learn how to install, configure and administer the ALI 6x portal. It is also for the person wanting to understand how to conduct an ALI implementation project. In three days you will implement a portal that can be used as a departmental solution. All aspects of ALI are reviewed including MyPages, Automation Servers, Search, Web Services, Portlets, Communities, Experience Definitions, the Knowledge Directory, and best practices to keep the portal up and running smoothly.
Course Modules
  • ALI Architecture
  • Basic Troubleshooting of the ALI Environment
  • Configuring the Automation Server and Jobs
  • Performing Routine Portal Maintenance
  • Creating an Administrative Hierarchy
  • Configuring Portal Access and Permissions
  • Implementing Advanced Object Security
  • Community Fundamentals
  • Creating a Community
  • Advanced Community Topics
  • Building Subportals
  • Configuring ALI Web Services
  • Importing Users and Groups
  • Extending the User Profile
  • Adding Content to the Portal
  • Maintaining the Knowledge Directory
Exercises
  • ALI Enterprise Planning Role Play
  • Using PTSPY and the Migration Utility
  • Using the Admin Hierarchy
  • Creating a Community
  • Creating a Subportal
  • Registering an Authentication Source
  • Registering a Profile Web Service
  • Managing the Knowledge Directory
After the training, the student should be able to:
  • Register Automation Servers
  • Create, run and troubleshoot Jobs
  • Perform routine Portal maintenance
  • Use PTSPY and the new Migration Wizard
  • Create Users and Groups in the Portal  Set up Activity Rights for users
  • Manage permissions using Access Control Lists
  • Create Communities
  • Create Projects in Collaboration Server
  • Create Experience Definitions and understand their use
  • Configure Web Services
  • Configure an AD Authentication Web Service
  • Configure a User Profile Web Service
  • Understand all of the content management objects in the Portal
  • Create a Crawler to allow access to external content through the Portal
  • Maintain Portal content and its search index
  • Implement Portal best practices

ALI Portlet Development

This course is an all-inclusive portlet development course that will coverbasic through advanced ALI Portlet development concepts. Although there is a small lecture component, the course is primarily exercise-based. Students who meet the prerequisites and who successfully complete all of the exercises will leave the course ready to design and write enterprise class ALI Portlets.
Prerequisites:
Basic understanding of the Plumtree Portal, MPPE & Portlets; proficiency in Java or C#; proficiency in web programming.
Course Modules/Exercises
  • Introduction to ALI, the MPPE, Portlets & C#/.NET or Java
  • Demonstration of ALI Portal and Integration Products
  • Install a Java IDE and come up with an idea for a new Portlet
  • Design an ALI Portlet and create a associated objects; add to MyPage and Community
  • HTTPGP/MPPE & the Gateway
  • Yahoo! Search Portlet: Design a portlet that allows the user to issue a search in Yahoo!
  • TCP Tracing: Use a free utility to trace TCP activity on port 80 (HTTP); observe CSP in action
  • Interaction Development Kits
  • Gateway Specific Configuration
  • Design an ALI Portlet that uses a Gateway Setting
  • Introduction to Settings
  • Change Font Color: Use a Portlet Setting to allow the user to personalize the Portlet with a font color
  • My Bookmarks: Design an ALI Portlet that displays an end-user customizable list of bookmarks to web sites
  • Settings Review
  • Community Bookmarks: Design an ALI Portlet that allows the community manager to set a customizable list of bookmarks to web sites
  • Introduction to Portlet Frameworks and Database-driven Portlet Design
  • Database Schema: Design database schema for a Data
  • Entry and Browse Framework Portlet
  • Administrative Settings Review
  • Administrative Settings: Design the Administrative Preferences page for a Data Entry and Record Browse Framework Portlet
  • Data View/Entry Form: Design Data View/Entry Form for a Data Entry and Record Browse Framework Portlet
  • Record Browsing: Design Record Browsing for a Data Entry and Record Browse Framework Portlet
  • Portlet Caching, Performance and Scale-ability
  • Caching: Add ETAG/IF-NONE-MATCH caching to Data Entry and Record Browse Framework Portlet
  • Enhance Record Browsing with Pagination, Sorting and Filtering
  • Internationalization/Localization
  • Create a Localized Portlet

Four ALI IDKs at your Disposal — Fifth One on the Way?

As most of you already know, there are four IDKs out there in IDK-land. To take a step back, if you’re really new to ALUI (formerly Plumtree) development, you can read about how ALUI handles portlets and how an IDK helps you write portlets. So, back to the four IDKs. They are all freely-downloadable from BEA — I’ve included links here:

*These two IDKs were written by developers at bdg and then released to the open source community on dev2dev’s CodeShare.

edocs warns you in boldface type: always use the IDK. That’s sound advice, given that the IDK API isolates you, as a portlet developer, from changes to the underlying protocol that ALUI uses to communicate between the portal and portlets (CSP). However, what if you’re not writing a portlet in Java, .NET, Ruby or PHP? As an aside, once upon a time, there were Perl and ColdFusion GDKs (predecessor to the EDK/IDK), but these development kits are no longer maintained by anyone, although I know for a fact that the ColdFusion GDK is still in use by an ALUI customer because it came up during a sales call!

So, back to my “what if” question: how can you write a portlet without an IDK? It’s actually not too hard if you’re just getting information from the portal. However, it gets challenging when you start setting preferences and then it starts to get really painful when you start dealing with Unicode issues, encrypted settings and some of the other really hairy stuff. So that’s why edocs implores you to use an IDK, when one is available.

If you do go down the road of writing a portlet in a language where an IDK isn’t available, I highly recommend that you at least abstract out your CSP calls such that they’re isolated from the rest of your portlet code. While you’re at it, you might as well follow the same API that BEA uses; in other words, write your own IDK (or at least the parts of it that you need to get your portlet done). To get you started, here’s how BEA probably implemented one of the IDK methods in Java:

public AggregationMode getAggregationMode() {
  if (!request.isGatewayed()) {
    throw new NotGatewayedException("Request not gatewayed.");
  }
  
  if (request.getHeader("CSP-Aggregation-Mode").equals("Multiple"))
    return AggregationMode.Multiple;
  } else {
    return AggregationMode.Single;
  }
}

So, go forth and write your own IDK. Or, preferably, ask a bdg-er to write one for you!

On a related note, one of our customers recently asked us to build an IDK for Lotus Notes/Domino in LotusScript. We’re trying to figure out if other people might be interested in this IDK so that we can decide if we’re going to open source it or do it as a consulting project (or some hybrid of the two). If you are interested in LN/Domino development for ALUI, let us know by commenting on this blog. I always love hearing feedback from users of the PHP and Ruby IDKs as well.

Comments

Comments are listed in date ascending order (oldest first)

  • Hi Chris. We have a couple of remote portlets on web servers running Perl so I looked around for awhile for the original Perl IDK but couldn’t locate it, so I’ve written a Perl module that supports the methods provided by IPortletRequest. They’re read-only methods but are really all we needed access to. man-page is here…
    http://webdev.co.nz/Perl/IPortletRequest.txt Is this worth placing in codeshare do you reckon? I don’t see a lot of action in the forums concerning Perl use.

    Dean Stringer ([email protected])

    Posted by: deeknow on March 22, 2007 at 2:00 PM

  • Hello Dean! The original Perl GDK was written so long ago that I’m not sure how much good it would do. It was based on CSP 1.0 and it followed the old GSServices API rather than the new com.plumtree.remote.portlet API.

    I’m pretty stoked to find out that someone else has written at least part of an IDK — that’s impressive. Do I think it’s worth posting to CodeShare? I haven’t heard much talk about ALUI and Perl, but I guess it can’t hurt.

    Posted by: bucchere on March 22, 2007 at 5:03 PM

  • Hi, Chris. We would love to have a Lotus Notes/Domino IDK available to us, as we have lots of “legacy” applications in Domino that we want to expose in ALUI, and an IDK would certainly help! Just my nickel’s worth… 🙂

    Posted by: kcepull on March 30, 2007 at 11:21 AM

  • Thanks for your comment. If you don’t mind my asking, would you be willing to pay for such a thing or is it only a nice-to-have that you would download and use if it were opensource, but not pay for it if it were a commercial product?

    Posted by: bucchere on March 31, 2007 at 6:07 PM

WLP + Adrenaline = ALI?

I recall sitting in a meeting in 1998 where we were discussing how to aggregate portlet content into a portal page. We talked a lot about iframes but couldn’t consider them as a serious integration option because of security, scalability/performance, caching and portal-to-portlet communication. Instead, we spent the next year building and testing the HTTPGadgetProvider, which later came to be called the “(Massively) Parallel Portal Engine.” (The term “Massively” was later dropped and I believe the name “Parallel Portal Engine” or PPE for short finally stuck.) I won’t go into details about how the PPE works, but if you’re interested, you can check out this great page in edocs that sums it up nicely.

So anyway, iframes are certainly reasonble way to build a portal in a day. But, in terms of building a robust enterprise portal that can actually withstand the demands of more than say, ten users, and that will pass even the most rudimentary security evaluation, iframes are complete nonsense.

So, today, during my lunch break, I attended Peter Laird’s Webinar, which he advertised in his nascent blog. It was all about enterprise mashups, a topic by which I’m very much intrigued. (Recall that PTMingle, my winning entry in the 2005 Plumtree Odyssey “Booth of Pain” coding competition was a mashup between Hypergraph, Google Maps, del.icio.us and Plumtree User Profiling.)

Imagine my surprise when Peter described how you can mash up Google “Gadgets” and other resources available via URLs using Adrenaline, a “new” technology from the WLP team based on, of all things, iframes. It was like entering a worm hole and being transported back to 1998. (I was single again, I had no kids, I was thinner and I had more hair on my head . . . and less on my back.) But the weird thing about this parallel universe is that BEA engineers were telling me that iframes were a great way to mashup enterprise web content and that intranets all over the world could benefit from this revolutionary concept. Intranets? You mean the things that everybody replaced with portals in the last millennium? Iframes? I must have been dreaming . . . .

When I finally came back to my senses, a few things occurred to me.

First of all, it’s 2007. Portals are a thing of the past. For some of us, that will be a hard pill to swallow. But let’s face it, innovators have moved on to blogging, wikis, tagging/folksonomies and lots of other nice web 2.0 sites that all have rounded corners. The bleeding edge folks have decided that many is smarter than any. The rest of the world will catch up soon.

Secondly, if you are still building a portal or composite application of any flavor, iframes are not a viable solution. They fall short in the following ways:

Portal-to-Portlet Communication

Say you want to send information (like the name of the current user) down to a portlet running in an iframe. Hmmm, the request for an iframe comes from the browser, not from the portal. So, if anything needs to be passed into the iframe, I guess you have to put in in the URL in the request for the iframe. That’s great, but that URL is now visible in the page’s source. So a simple, “Hello [your name]” portlet where the portlet gets the name from the portal is doable. But what about passing a password? That information would need to go first to the browser and then back to the remote tier, which, from a security standpoint, is a complete showstopper.

Security

Let’s talk a little more about security. Since you’re using an iframe, the requests aren’t proxied by the portal. Instead, a page of HTML gets sent from the portal to the browser and then the browser turns around and makes requests to all the iframes on that page. Since the portal isn’t serving as a proxy, it can’t control what you do and don’t have rights to see, so security is completely thrown out of the window. (Or should I say, thrown out of the iframe?) Moreover, in an enterprise deployment, the portal usually sits in the DMZ and proxies requests out to bits and pieces of internal systems in order to surface them for extranet users. If you’re using iframes, every bit of content needs to be visible from an end user’s browser. So what’s to stop an end-user from scraping the URL out of a portal page and hitting a portlet directly? Nothing! (If I understand what I’m reading correctly, the WLP team is calling this a feature. I would call it a severe security risk.)

Scalability/Performance

Yes, this approach will work for Google Gadgets. But Google has more money than pretty much everyone. They can afford to spend frivolously on anything, including hardware. However, the rest of the world actually cares about the kind of load you put on a system when you create a “mashup.” A page consisting of five iframes is like five users hitting the sites with five separate requests, separate sessions and separate little “browsers.” If any of the iframes forces a full-page refresh or if the user does the unthinkable and say, moves to another page, every request is reissued and the mashup content is regenerated. This simply does not scale beyond a few users, unless you have as much money and as much hardware as Google does.

Caching

A properly designed portal or content aggregation engine will only issue requests to portlets when necessary. In other words, each remote portlet will only get a request if it needs to be loaded because the portal doesn’t have a cached entry. Unfortunately, you can’t do this with iframes because the portal doesn’t even know they exist. (Remember, all requests for iframe content go directly from the browser to the remote content, bypassing the portal entirely.)

What baffles me is why a company would acquire another company with a revolutionary technology (the PPE) and then start from ground zero and build a technology that does the same thing but without a portal-to-portlet communication model (preferences), security, scalability or caching. If consumers weren’t already confused, now they most certainly are.

As technologists, I hope you can see through the hype about Adrenaline and consider a product that actually allows you to mash up web content in a scalable and secure way and has been doing so since 1999. It’s called AquaLogic Interaction and it’s sold by a company we all know and love called BEA.

Comments

Comments are listed in date ascending order (oldest first)

  • I just discovered that the BID/AquaLogic (formerly Plumtree, Fuego, Flashline, etc.) folks are having another webinar, entitled “Harnessing Enterprise Mash-ups with Security and Control.” This webinar (I hope) will show:
    1. how ALI has been handling mashups since before mashups was even a buzzword and
    2. how Project Runner enables next generation mashups that allow you to invoke back-end applications and provision security, branding, SSO, etc. without actually funneling everything through the portal.

    If you were at today’s webinar and you’re now wondering how to do mashups with more robustness and security, then I hope you’ll attend this webinar. By all means, it’s just the responsible thing to do in order to offer customers different integration options when creating their mashups.

    Posted by: bucchere on January 10, 2007 at 7:31 PM

  • I’d like to add a couple points of clarity from BID product management. First of all, we’re happy to have passionate developers, but I fear this post may give the wrong impression about some of BEA’s technology and plans.

    WLP Adrenaline, ALUI, and project Runner are all complementary technologies that have a very exciting future when applied to problems such as Enterprise Mashups. You’ll be hearing more about them from BEA over the coming months through various venues, including Webinars targeted at WLP-specific use cases (such as Peter’s excellent talk) and ALUI use cases (including tomorrow’s Runner Webinar). There will also be the usual blogging and other activities.

    Just as WLP and ALUI product teams are aligned, these different technologies are aligned. Adrenaline offers WLP customers a way to extend their reach in fundamentally new ways, and Peter will expound on some technical subtleties to address some of Chris’ concerns. Runner, too, is very exciting, enabling a completely different set of use cases. As the details unfold we’ll demonstrate how well aligned these technologies are — just wait until you see them working together!

    – David Meyer

    Posted by: dmeyer on January 10, 2007 at 10:41 PM

  • Just for those that don’t know about Adrenaline, here’s an article introducing Adrenaline.

    Posted by: jonmountjoy on January 11, 2007 at 12:19 PM

  • Chris,

    As David writes, BEA is moving ahead with multiple approaches to address the enterprise mashup space. My webinar covered the approach WLP is taking, and in no way implied that ALUI is not also a viable player in this space. We offer our customers a choice of products, and different products make sense to different customers.

    As for the specific issues you raised:

    ** Technical Reply

    Good technical points, but I think you overemphasized the role of iframes within WLP. Let me cover the two places we showed the use of iframes:

    Use Case 1: injecting a portlet into a legacy webapp

    Demo: An iframe was used in the demo to inject a portlet into a legacy static html page with almost no modification to that page (one line change).

    WLP does support an alternative approach – an Ajax streamed portlet. I simply did not have time to demo it. Also, this is not a portal use case for including external non-portal content into a Portal; instead it is the inverse, which is to publish existing portal content into legacy web applications . It was intended to show a very inexpensive way to energize a dated application until it is rationalized into a portal. The focus here is on minimizing cost of supporting legacy, while building portlets in transit to a portal solution.

    Use Case 2: WLP as a Mashup composition framework

    Demo: Iframes were used to pull in non-WSRP capable components (e.g. Google Gadgets) onto a WLP page

    First, as background info, the WLP architecture supports the rendering of various types of portlets:

    • Local portlets (deployed within the webapp, JSF, JPF, etc)
    • WSRP portlets – an advanced remoting approach which handles security, inter-portlet communication, etc…
    • Iframe portlets – an available remoting approach
    • WLP partners with Kapow for remote clipped portlets (similar to the ALUI approach)

    In regards to this use case, you brought up specific concerns:

    Security

    Concerns about shared authentication were noted in my talk. If components come from outside the enterprise, there is no easy solution to that problem, regardless of what product you are using. However, I spoke of a couple approaches in the webinar, including SAML.

    If those components come from inside the enterprise, the security hacks you were referring to are generally not necessary. Our customers that expect SSO have a web SSO solution (typically, cookie powered, not password in the URL powered) in place within the enterprise.

    Caching/Performance

    The most serious concerns of yours appear to be performance related. Specifically, the concern is that a full page refresh of a page that contains N number of iframes will cause an N+1 number of requests. To expand on your concern, I will add that this is not only seen in pages with iframes, but also pages that use Ajax to pull in data. I would say that there are several reasons why this does not invalidate WLP’s approaches:

    1. Mashup pages with lots of iframe portlets approach

    Google Personalized Home Page makes use of iframes to implement their mashup framework. Many of the Gadgets on the page are rendered with an iframe. But you are mistaken in saying that this scales because Google is throwing tons of hardware at the problem. The iframe Gadgets rendered in GPHP are rendered not by Google, but by 3rd party gadget hosting servers around the world. Google does NOT have to process those iframe Gadget requests, it is a distributed approach. Likewise, you could create a WLP page where most of the portlets are iframe portlets that hit a distributed set of servers, if that makes sense. Or…

    2. Mashup pages with a mixture of portlets

    The 2nd demo in my webinar wasn’t showing a page with all iframe portlets. Rather, what the demo was showing was a WLP page with a couple of iframe portlets mixed in with local portlets. As shown above, WLP supports a number of portlet types, and a good approach is to build pages that are a mixture of that set.

    3. Ajax helps minimize page refreshes

    Your concern about iframe performance stems from the case in which the entire page refreshes. With the usage of Ajax becoming common, plus with WLP 9.2 built in support for auto-generating Ajax portlets, this impact can be minimized. Page refreshes are becoming more rare. With WLP 10.0, which releases in a few months, the Ajax support has been expanded to support Ajax based portal page changes, further reducing the liklihood of a page refresh.

    4. The “Bleeding Edge” guys are also using browser based mashup approaches

    You referred to the “Bleeding Edge” technologists in your blog as the people that are doing things correctly. What are they doing? Some of the time, those guys are doing browser based Mashups. They often use a combination of iframes and Ajax from the browser to implement their mashups. So the same approach that you dislike is already in common use across the web.

    ** Market Reply

    You state “Portals are a thing of the past”. An interesting opinion, but just that. IT cannot afford web sprawl, and so a framework for rationalization will always be in demand whether you call it a Portal or something new.

    New technologies continue to provide alternatives to existing methodologies and portals are no different. However, one thing that has distinguished portal frameworks is their ability to embrace new technologies. Struts, WSRP, JSF are all examples of this as are the Web 2.0 constructs like mashups and rich interfaces based on Ajax. This is all good news as the enterprise has a wealth of options to choose from.

    Posted by: plaird on January 11, 2007 at 2:56 PM

  • I must say, as a customer and developer, it’s great plumtree (I mean BEA, or is it Oracle) management allows you guys to express your own opinions. It so happens I’ve spent quite a bit of time trying to get JBoss Seam (and Ice Faces) to work with Aqualogic 6.1. I’ve been looking at the IFrame route, because the gateway stuff just isn’t working (it doesn’t properly rewrite the URLs for the Ajax stuff). I’ve come to hate the gateway. I bet it was a great idea before Ajax, but now it seems like almost every web 2.0 application is incompatible (needs major modification to get it to work). Or maybe I just don’t understand how to get it to work. Is there any good documentation on it? I’m hoping for some major improvements when 6.5 comes out though.

    Posted by: cmann50 on April 4, 2008 at 2:28 PM

How to Integrate PKI Certs or CAC Cards with ALI

In his 1947 speech to the House of Commons, Winston Churchill quipped, “It has been said that democracy is the worst form of government except all those other forms that have been tried.”

I’m not nearly as pithy as Sir Winston (nor as portly — at least not yet), but yet I feel the same way about passwords being used to protect web sites or other enterprise systems. In many ways, they’re the worst form of security out there except for everything else that’s been tried. Part of this has something to do with what I’ve coined Bucchere’s Axiom of Strong Passwords, which is a derivative of Murphy’s Law (which states that whatever can go wrong will). It goes something like this: the stronger a password is, the easier it is to hack. Why? Because if you force users into using a strong password, they’re more likely to write it down. And writing a password down defeats its purpose entirely.

The bottom line: passwords suck. But they’ve become the de-facto standard because they’re easier and cheaper than everything else we’ve tried, including PKI certs, biometrics (e.g. fingerprints, retina-scans), CAC cards, RSA secure IDs, etc. (Even for a cert-based authentication scheme, you still need a key to generate your cert, which is essentially just a glorified password.)

Just because passwords are the de-facto standard for authentication does not mean that we should quit trying to use other, ostensibly better forms of security, especially if 1) you’re protecting particularly sensitive data, 2) you’re open to the internet and 3) you have the resources (e.g. $$$) to invest in more robust forms of security. And I’m not talking about just buying an SSL cert from Verisign and continuing to have your users write down their passwords on post-it notes attached to their monitors. (Note to self: remove the post it note on your monitor with your password on it when you get back to the office.) I’m talking about using some sort of “soft” cert (e.g. PKI) or “hard” cert (e.g. CAC) to protect your system and your data.

Now if your system is ALI (formerly known as Plumtree Foundation or Plumtree Portal), you’re in luck, because the eggheads at what was once known as Plumtree have made this particularly easy to do. In fact, the hardest part is just getting the user’s identity out of the cert (see below the code snippet for some suggestions). Once you’ve done that, just drop a class into a jar that implements the ISSOProvider interface. (For those of you running on Windows, please don’t ask me to “port” this to C# — just take the Java code, drop it into Visual Studio.NET and then fix the syntax errors.)

But wait, SSO stands for “Single Sign On,” right? And what you’re really doing here is passing credentials from a cert to Plumtree and that has little or nothing to do with SSO. That’s a true statement. The subtlety here is that ISSOProvider, while it contains the letters SSO in its name, can be used for pretty much any form of authentication, whether you are using an SSO product or not.

CertIntegration.java

package com.bdgportal.alui.auth;

import com.plumtree.openfoundation.util.*;
import com.plumtree.openfoundation.web.*;
import com.plumtree.portaluiinfrastructure.sso.*;

public class CertIntegration implements ISSOIntegration {
 
   private XPHashtable settings;
 
   public CertIntegration() {
     ;
   }
 
   public boolean Initialize(XPHashtable settings) {
     this.settings = settings;       
     //String exampleSetting = ((XPArrayList)settings.GetElement("SettingName")).GetElement(0);
   }

   public String GetSSOProductName() {
     return "My Favorite Cert Integration";
   }

   /**
    * Gets the username from the cert and returns it to Plumtree. This will fail if the username
    * does not have a matching account in Plumtree. This can be a Plumtree database user or a user
    * imported from an authentication source, in which case you need to include the auth source
    * prefix in the username, e.g. "MyAuthSource/cbucchere"
    *
    * @param request The wrapped HttpServletRequest from the web container.
    * @return The object passed back to Plumtree for authentication with the portal.
    */
   public SSOLoginInfo GetLoginInfo(IXPRequest request) {
     String userName = ((XPRequest)request).GetUnderlyingObject().getUserPrincipal().getName();
     return new SSOLoginInfo(userName);
   }

   public String[] GetSecureCookies() {
     return null;
   }

   public String[] GetSecureHeaders() {
     return null;
   }

   public boolean OnLogout(IXPResponse response, String returnURI) {
     return false;
   }   
}

The hardest part about all this, as I said above, is getting the user name out of the PLI cert/CAC card/retina scan/etc. In the example above, I made MANY assumptions. First, I assumed that your portal is running on Weblogic, which understands and correctly implements Principal, which is a Java Servlet’s way of knowing who’s using it. Weblogic lets you plug custom implementations of the Principal class into its security infrastructure. All you need to do is extend java.security.Principal and then walk through a bunch of magical configuration steps to enable it.

Speaking of magical configuration, I neglected to mention that there are two small configuration steps that you need to perform in order to get your shiny new ISSOIntegration working in ALI. In portalconfig.xml, you need to set the value of SSOVendor setting to 100 (or greater) and then set the CustomSSOClass to the fully qualified name of the class you wrote that implements ISSOIntegration. For our Java example above, that would be com.bdgportal.alui.auth.CertIntegration and for .NET, it would the the name of your C# class.

Speaking of .NET . . . as many of you know, it is an entirely different animal with its own way of provisioning security to web applications (e.g. System.Web.Security).

Regardless of your platform, you need to get the user name out of whatever authentication method you’re using. Once you’ve accomplished that, just drop the code above into your project and replace the getUserPricipal().getName() with whatever mechanism you can find for getting your users’ names.

Assuming you trust your authentication mechanism to return the appropriate user name, you’ll have users getting logged into the portal via pretty much however you would like — CAC, PKI, biometrics, etc.

If only implementing a democracy were this easy . . . .

Comments

Comments are listed in date ascending order (oldest first)

  • This is wonderful article. How ever I’ve researched for a long time but still can not figure out what to do with Bea Weblogic to use Costom Identify Assertion. I wish this artical to have link to the document of how to “do the magical configuration steps”.

    Posted by: minh.tran on January 9, 2007 at 9:04 AM

  • This article was intended to be application server independent, but if you’re using BEA WebLogic, there’s a great article on how to set up custom identity providers which should work with this ALUI SSO solution.

    Posted by: bucchere on January 10, 2007 at 6:44 PM

  • NOTE: 1. the user’s password in the portal must be empty string. 2. jar should be put in portal.war and lib/java.

    Posted by: luotuoci on April 28, 2007 at 8:31 PM

The Ruby IDK

It’s here: The little integration kit that could change the world. Thanks to the efforts of hotshot bdg developer Andrew Bays, the Ruby IDK is now rockin’ on BEA’s dev2dev CodeShare. Visit the project at https://rubyidk.projects.dev2dev.bea.com and start a discussion thread if you like.

Like all the best things in life, the Ruby IDK is free. It comes as a Rails project, so just unzip it and type ruby script/server and off you go developing Ruby/Rails portlets to your heart’s content. Enjoy!