Middleware for the REST of us

bea_think_oracleI’m sitting in my third Oracle Fusion Middleware briefing, this one at the Willard Hotel in Washington, DC. Thomas Kurian has been going through all the products in the Oracle stack in excruciating detail.

First let me say this: Thomas Kurian is a really smart guy. He holds an BS in EE from Princeton summa cum laude (that’s Latin for really fucking good). He holds an MBA from the Stanford GSB. He’s been working for Oracle forever and he even knows how to pronounce Fuego (FWAY-go). I’m dutifully impressed.

Unfortunately, all those academic credentials and 10+ years in the industry is barely the minimum requirement for getting your head around the middleware space. Either I don’t have enough (0) letters after my name, or I just don’t get it.

For starters, there are way too many products — the middleware space is filled with “ceremonious complexity” (to quote Neal Ford). App servers, data services layers, service buses, web service producers and consumers — even portals, content management and collaboration has been sucked into this space. Don’t get me wrong: the goals of the stack are admirable — middleware tries to glue together all the heterogeneous, fragmented systems in the enterprise. Everyone knows that most enterprises are a mess of disparate systems and they need this glue to provide unified user experiences that hide the complexity of these systems from the people who have to use them. That makes the world a better place for everybody.

That was also, not coincidentally, one of Plumtree’s founding principles and the concept — integrating enterprise systems to improve the user experience — has guided my career since I got my lowly undergraduate degree in Computer Science from Stanford in 1998.

So, it’s a good concept, however, if you’re considering middleware because you’re trying to clean up the mess that your enterprise has become, you need to ask yourself the following fundamental question:

Does middleware add to or subtract from the overall complexity of your enterprise?

Your enterprise is already insanely complicated. You’ve got Java, .NET, perhaps Sharepoint, maybe an enterprise ERP system like SAP and say, an enterprise open source CRM system like SugarCRM or a hosted service like SalesForce.com. The bleeding edge IT folks and even (god forbid) people outside of IT are installing wikis written in PHP (e.g. MediaWiki) along with collaborative software like Basecamp written in Ruby on Rails. I’m not even going to mention all the green-screen mainframe apps still lurking in the enterprise — wait, I just did. This veritable cornucopia of systems just scratches the surface of what exists at many large — and even some mid-to-small-sized companies — today.

So clearly there’s a widespread problem. But what’s the solution?

At the end of his impressive presentation, I asked Thomas the following question:

“How can middleware from Oracle/BEA help you make sense of the fragmented, heterogeneous enterprise when you have existing collaborative (web 2.0) technologies written in PHP, Ruby on Rails, etc. running rampant throughout IT and beyond?”

(Okay, so I wasn’t exactly that pithy, but it was something close to that.)

His Aladdin-esque answer came in the form of three choices:

    1. “Take control of” and “centralize” your IT systems by replacing everything with Oracle Web Center spaces
    2. Ditto by migrating everything to UCM (Stellant)
    3. Build a services framework and aggregate everything in one of four ways:
        1. Use a Java transaction layer (JSR 227)
        2. Use a portlet spec like JSR 168 or WSRP
        3. Build RESTful web services
        4. Use the WebPart adapter for Sharepoint

      I like to call answers one and two “The SAP Approach.” In other words, we’re SAP, we’re German, wir geben nicht einen Scheiße about your existing enterprise software, you’re now going to do it the SAP way (or the highway).

Will companies buy into that? Some companies may. Many will not. ERP is a well understood space, so this approach has worked for SAP. Enterprise 2.0 is not terribly well understood, so that means even more diversity in the enterprise software milieu.

So the only approach that I believe in is #3: integrate. Choose the right tool for the right problem, e.g. the WebPart adapter if you’re using Sharepoint. Use REST when appropriate, e.g. when you need a lightweight way to send some JSON or XML across the wire between nonstandard or homegrown apps. Use JSR 168/286 for your Java applications. Even use SOAP if the backend application already supports it.

Keep things loosely coupled so that you can plug different components in and out as needed.

This requires a lot of development — the glue — but, I don’t think there’s any way around that. (You should take that with a grain of salt, because my company has been supplying the government and the commercial world with exactly that kind of development expertise since 2002.)

As for the overarching, user facing “experience” or “interaction” product — that’s where I’ve always used Plumtree (or AquaLogic Interaction).

Will I start using Web Center Spaces? At this point, I’m still not sure.

If it can be used as the topmost bit of the architectural stack to absorb and surface all the enterprise 2.0 software that my customers are running, then perhaps. If it’s going to replace all the enterprise software that my customers are running, then no way José.

This conundrum really opens up a new market for enterprise software: I call it “Middleware for the REST of us” or MMM (not M&M, 3M or M3, because they’re already taken): “Mid-Market Middleware” — similar to the way 37signals approaches (with a great deal of hubris and a solid dose of arrogance) the “Fortune Five Million” by marketing their products toward the whole long-tail of small and medium-sized companies. Maybe the world needs a RESTful piece of hardware that just aggregates web services and spits out a nice UI, kind of like the “Plumtree in a Box” idea that Michael Young (former Plumtree Chief Architect, now Chief Architect at RedFin) had back in the last millennium.

Oracle Web Center Spaces might be the right choice for some very large enterprises, but what about the REST of us?

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

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

Plumtree releases G6

Late yesterday, Plumtree announced the release of their G6 line of products. They have made everything generally available for download for partners and customers at portal.plumtree.com.

A couple things have been renamed. The Portal has become the “Foundation,” Content Server has become “Publisher,” Authentication Web Services have become “Identity Services,” Crawler Web Services have become “Content Services,” the .NET Web Controls have had the word “Consumer” tacked on the end, and the EDK (once known as the GDK), is now contained within something called the PDK. Not sure what happened to the WSRP container, but the JSR 168 container has been updated for G6 as well.

The major difference is that the Foundation product and many of the services are now entirely Java-based or entirely C#-based. This means some interesting things, including the fact that although Plumtree is only officially supporting RedHat Linux 3 ES Update 3 right now, there’s a good chance that the Java version will run (and run well) on other versions of Linux and even on Solaris or even Solaris X86.

On Windows, the support matrix includes IIS 6.0 and SQL Server 2000 SP3a.

For the non-Microsofties, Oracle 9i and Oracle 10G (with or without RAC) are supported along with Tomcat 5.0.28, IBM WebSphere 6.0.1 and of course BEA 8.1 SP4.

If you’re just silly like that, you can also run any of those configurations on Windows, but I’d have to ask you “why?!?” if you did. 😉

Major feature differences include a re-tooled (and now web-based) object migration, enhanced subportals (now called user experiences), improved user syncrhonization, enhanced Snapshot Queries and Best Best, and improved tools for integrating existing web applications into the portal.

Everyone at bdg is excited about this release and we look forward to helping our customers upgrade to the latest and greatest, starting whenever they’re ready.

The future of JSR-168

There is some interesting speculation about the future of JSR-168 going on at the Portlets Yahoo! Group. IMO (which is a redundant thing to say because this whole blog is My Opinion), I don’t think the spec is going away by any means. But at the same time, it seems that the entire industry has come to recognize it as the “lowest common denominator” of portlet functionality. In terms of features, it fails to specify portlet-to-portlet communication APIs among several other things. But worst of all, it’s designed with the presumption that the portlets will always run inside the portal container. Humph.

Is Plumtree an “open” platform?

“We call this re-imagining Radical Openness. Radical Openness is our strategy to offer both J2EE and .NET versions of our entire application management framework, new points of integration for synchronizing the Enterprise Web environment with systems of record as well as desktop tools, and the ability to embed Enterprise Web services in any Web application,” Kunze continued. “Ultimately, we believe the way applications are being developed is fundamentally changing, and that with the Enterprise Web, applications can be developed in greater volumes, at lower cost, and on a wider variety of platforms than ever before.” –John Kunze, CEO, Plumtree, Inc. (excerpted from a 2003 press release).

bdg‘s response to this is that in some ways it is and in some ways it isn’t.

Plumtree is Open:

  • It runs on Windows (.NET or Java) or Solaris (Java)
  • It can embed portlets from anything that speaks HTTP(S)
  • It uses SOAP over HTTP for Crawlers, Authentication, Profiling and Search
  • It uses other nice, open-ish technologies like XML, SQL, HTML, CSS, Javascript
  • It runs on SQL Server or Oracle

Plumtree isn’t Open:

  • It only runs on only Windows and Solaris, not AIX, HP-UX, Linux, or any other *nix
  • It’s entire codebase, though highly pluggable and configurable, is proprietary
  • It uses proprietary headers (CSP, which stands for Content Server Protocol, no relation to Plumtree’s Content Server, don’t ask 🙂 to communicate information to and from portlets*
  • It only runs on SQL Server and Oracle, not MySQL or any other RDBMS

*Plumtree does support both WSRP and JSR-168 through plug-ins, though they limit functionality to some degree (more on this later).

I should preface all of this by saying that I still believe Plumtree is far and away the “best” portal solution for most mid- to large-size corporate intranets and even extranets for a whole host of reasons. I mean really, why would I bet my company on it if I didn’t?

However, it’s easy to confuse “open” with “pluggable” when they are in fact very different. When I hear things like, “my web service is written in Ruby on Rails, but .NET, Java and PHP clients use it all the time,” then I think “open.” (And no, if you’re wondering, I’ve never actually heard that, not even from Dave Thomas.) When I hear, “sure, you can replace the page navigation in my presentation layer, but only if do it with Tapestry” then I think “pluggable.”

Plumtree’s UI is pluggable; their WS/PRC server, EDK, CWS, AWS/PWS and SWS architectures are open; and their Portlets are, well, a little of both: they’re very open in that you can write them in anything that speaks HTTP(S), but only if you do it with their proprietary headers, but then, well, you can use JSR-168 or WSRP to get around that, but then, well, you can’t get all the functionality like Adaptive Portlets . . . .

When it comes to Plumtree’s Portlets (or Gadgets as they used to be called), it almost sounds like I’m arguing with myself.

In summary, if you’re looking for a proprietary product that’s built on some open standards that you can extend using open standards (sometimes) but that only runs on certain platforms, well, then Plumtree is for you.

While I’m not in the business of making excuses for Plumtree, I must say that every time a company with a proprietary enterprise software product needs to support a new OS or browser or database or “thingy” they need to run that combination through a testing matrix that grows exponentially each time you add a new “thingy” to it. That is a royal pain in the proverbial backside.

The complexity of the testing matrix alone is a great argument for open sourcing everything. (And yes, I understand that open and open source are not the same thing.) While I do see merit in commercial, proprietary software, I assure you that if Plumtree’s code base were open source it would already be running wild on Linux. Why? Because I would have compiled it myself. 🙂