my recent reads..

Atomic Accidents: A History of Nuclear Meltdowns and Disasters; From the Ozark Mountains to Fukushima
Power Sources and Supplies: World Class Designs
Red Storm Rising
Locked On
Analog Circuits Cookbook
The Teeth Of The Tiger
Sharpe's Gold
Without Remorse
Practical Oscillator Handbook
Red Rabbit
Showing posts with label WebCenter. Show all posts
Showing posts with label WebCenter. Show all posts

Monday, July 07, 2008

OpenID - the missing spice in Enterprise 2.0?

I have been playing around with OpenID recently and considering its significance. OpenID offers a "single digital identity .. you can login to all your favourite websites", and its adoption is rapidly accelerating especially since services like Yahoo and Blogger have added OpenID support to the many millions of existing user accounts.

Maybe I'm missing something here, but I am surprised by the lack of attention OpenID is getting in the enterprise context.

And when it is considered, it is often as an either/or proposition. As Nishant Kaushik writes in his excellent identity blog:
.. simple web applications with minimal needs could get away with simply supporting OpenID. But that should not be confused with not requiring a full-fledged identity services infrastructure where appropriate.
I think this is somewhat misdirected; certainly not the whole story. OpenID-enabling existing applications for an external audience is already a trivial exercise. It's a simple API, and plugins or toolkits are available for most programming environments. I think the much bigger deal is looking at OpenID from the opposite perspective - using enterprise security infrastructure to support OpenID authentication.

In my view, OpenID is key to unlocking the true potential of "Enterprise 2.0", which is what I wanted to discuss here to try and explain my thoughts and get some feedback.

It may also lead us to think more clearly about what Enterprise 2.0 really is. This is the current definition up on wikipedia:
Enterprise social software, also known as Enterprise 2.0, is a term describing social software used in "enterprise" (business) contexts..
The "social" nature of Web 2.0 tends to get the headlines, and hence by simple transference must be to basis of Enterprise 2.0. Right?

However, I'm not convinced.

Expecting Enterprise 2.0 success by simply adopting social networking features of Web 2.0 just seems a little naive. For a start, it implies and requires phenomenal change in the social and organisational fabric of a company to get off the ground, and there is no guarantee the benefits will be worth the pain of change. In many organisations it may just be too much, too soon, and fail completely.

Much as I love them, I don't even think "mashups" will be the killer app for Enterprise 2.0.

I think the key is a much more mundane aspect of Web 2.0 that gets lost in the facebook frenzy: the simple fact that users are being exposed to just so darn many useful tools in the ever increasing range of web applications (or Rich Internet Applications aka RIA).

We see unprecedented utility in the applications on offer, approaching what we expect from desktop or dedicated applications. And there is an incredibly low barrier to participation - you can sign-up within a minute and with usually no immediate associated cost.

So my main proposition is that the quick win for Enterprise 2.0 is for companies exploit the RIA boom. Spend your time figuring out how to exploit the burgeoning Web Application offerings. Do NOT waste your time scheming how to clamp down on usage, or on replicating the tools yourself.

The real and immediate benefits include reduced IT spend, better utility and happier users .. and set the stage for moving to the world of "Advanced Enterprise 2.0" with mashups and social networking for example.

The caveat of course is that the enterprise must ensure that matters of availability, data protection, confidentiality and privacy are not compromised in making such a move.

But this presents a dilemma for the enterprise. A tough choice between undesirable outcomes:
  1. ban and fore-go the benefits of adopting external Web Applications for enterprise use;

  2. allow their use, but lose control of the data, identities and secondary use derived from using such applications;

  3. or be faced with re-implementing all those cool features within the firewall (and risk becoming disconnected from the external audience).


This leads us to the present state-of-the-art in Enterprise 2.0, which must necessarily work around the constraints of the corporate boundary.

  • Some companies are adopting External Web Applications where they address a largely external audience (a good example is the official Oracle Wiki which runs on wetpaint). But here they remain disconnected from internal systems.

  • For internal adoption of Web 2.0 technology, IT departments are often re-implementing all the cool stuff inside the firewall.

    The CEO wants a blog? Customer support want to setup a wiki? Sure, we can install it. Where install means friggin' around for a few months to select and acquire the software, integrate it with the standard enterprise security/monitoring/hosting/blah environment, customise it to the corporate branding etc etc.
Toto, I've a feeling we're not in Kansas any more.. suddenly Enterprise 2.0 doesn't seem so exciting.

And I think it denies the dirty little secret that I bet exists in most organisation: your employees are already using these services for business purposes!

Using a personal credential for business purposes on an external service (whether OpenID or not) presents a whole range of challenges:

  • It is a provisioning nightmare. What happens when the employee leaves? The company doesn't control the account, so it can't be disabled. Whether you can remove access from any corporate data held in the external service depends totally on the application itself and how it was setup.

  • For the individual, there is a concern about keeping their professional and private lives appropriately separated. Too easy for your tweets to end up in the wrong hands in the wrong context.

So what's a girl to do? I'd suggest the answer is pretty obvious - we need corporate identities that can extend beyond the boundaries of the the organisation in a safe and controlled manner. This was the intention with SAML, but adoption has been slow - I suspect hindered by the complexity of its WS-Deathstar burden - and now OpenID is streets ahead in terms of acceptance (an interesting parallel to the adoption of SOAP v. REST for SOA Web Services).

In other words, the key to all of this IDENTITY.

Imagine for a moment the ideal world. I would have a corporate identity that works transparently within the enterprise and also for useful external services. And I could keep this quite separate from my personal identity (even though I may use some of the same external services on my own time).


The question now is whether we are far from being able to achieve this? I think not...

The call to Enterprise Identity Management Stack providers..

That means Microsoft, Oracle, IBM, Sun and so on.. the companies that produce the security software that is managing your enterprise identity every time you sign in to an enterprise application.

Many of these guys are members of the OpenID Foundation, but on the whole it is hard to find clear statements of direction at the moment, and the initial focus has been around demonstrations of how they can use credentials from other OpenID providers.

We need to see two things in particular:
  • OpenID provider support in their core identity management stacks, so that enterprise credentials can be used as OpenID credentials under the control of the company (e.g. they can be disabled when the employee leaves). Call that part of a "Service Oriented Security" strategy if you like, just make the option available;-)

  • Include that ability to blacklist/whitelist sites that the credentials can be used for.

    There will always be good reasons why certain Web Applications may be off limits for corporate use. For example, a law firm may not be able to use Google Documents because of jurisdictional concerns.


Dion Hinchcliffe presented the case well in the recent article "openid: The once and future enterprise Single Sign-On?", along with a great visualisation:


The call to Web Application providers..

Firstly, the big guys like Yahoo! need to support third party OpenID credentials. This seemed to be the main thrust of Hinchcliffe's article. I hope this is just a matter of maturity and not business model pig-headedness, but to offer OpenID sign-in only if your OpenID provider is the same company is not really in the right spirit of things!

More generally applicable however is a major consideration for any Web Application provider that wants to target the enterprise market: addressing the security issue with OpenID support only opens the door. To step through, you must be ready to meet the specific demands of an enterprise customer.

First of these must be data ownership. I didn't want to focus on it in this post because I think it is an orthogonal concern to security. But if you want enterprise customers, be prepared to to consider requirements such as:
  • Access to all data owned by the company's users on the service. For backup, export, and analytics.

  • Audit and compliance

  • Service levels

The call to Enterprise Software vendors..

The idea of a "Web 2.0 appliance" is I think very attractive to many organisations: an easy on-ramp to the space without the need to build up a whole range of specialist skills within the company. In the appliance category I would include Oracle WebCenter and the new IBM Mashup Center. Needing OpenID authentication support in these products is of course a no-brainer in order for them to have appeal in cases where you wish to mix internal and external user audiences.

Enterprise Software vendors need to go further however. The enterprise of the future, which expects to operate seamlessly on the web, will need the ability to "export" corporate identity to the world. Right now, that means capabilities like having OpenID provider support in your Enterprise Identity Management services.

Given the state of consolidation in the industry however, OpenID may present a dilemma for vendors who are faced with the prospect of OpenID support in their Identity Management stack cannibalizing sales of their application suites, as users start to exploit external Web Applications.

But to be recalcitrant and stand against the move to OpenID will only accelerate the onset of a winner-takes-all showdown in the enterprise applications market.

Personally, I believe the showdown is inevitable: with the combined pressures of RIAs, cloud computing, oligopolistic pricing and increasingly sophisticated open source alternatives, I think it is quite likely we will see the enterprise software market go supernova within the next 5 years i.e. blow itself to pieces after a few more years of consolidation ... but that's a topic for another post perhaps;-)


The enteprise software vendors that survive will be the ones who truly embrace being open, and that includes OpenID.

Conclusions?

Well, I wonder if I've convinced anyone?

To me it seems that the ability for enterprises to add OpenID provider support to their security infrastructure will be the key to unlocking the full potential of Enterprise 2.0.

Until such a facility is available from the mainstream Identity Management vendors, we will just be messing around on the fringe.

NB: edited for clarity 9-Sep-2008

Saturday, March 15, 2008

Using OVD Filtered Directories for LDAP Authentication

Oracle Virtual Directory (OVD) is one of the little-known or understood hero products in the Oracle suite of technology offerings [I put OEM Grid Control in the same class].

In this post I'm going to share a few thoughts on OVD, and present a few approaches for using OVD to present a restricted view of information from another directory, and how that can be used to limit access to applications that use an LDAP authentication mechanism.

When I was first learning about OVD back in early 2007, after the Oracle acquisition, it immediately grabbed my attention. Simple, easy to use, but so powerful - a swiss army knife for anyone working in the directory management space. Maybe that is the wrong analogy, because the greatness in OVD is that it doesn't try to boil the ocean - it just does one thing, but does it really well.

Simply put, it allows you to combine directory-related information from disparate sources (LDAP, AD, database etc) and present an LDAP-compliant view in real-time. And the virtual bit is real (if that makes any sense) - OVD doesn't store anything, unlike a meta-directory; it just passes through the directory requests according to the rules you setup.

The virtual nature makes OVD ideal in large enterprise situations, where control of directories may be distributed. Another group may have a directory that contains some information you want to use as part of your "directory view", but are not going to cede any ownership or agree to any changes anytime soon, like adding some new attributes. Wheel in OVD!

Likewise, affiliated companies may want to share directory information, but not handover control. And if the business relationship comes to and end, the directory owners want to know that they can turn off access in a moment, without needing worry about cached or replicated data left on the other side of the corporate divide. OVD to the rescue!

Case in Point: you need a subset of an existing directory

The inspiration for this post is a small challenge I was involved with recently. The company was deploying a new web application - just happened to be Oracle WebCenter Wiki, but the same applies to any application that supports LDAP authentication.

The only directory available contained a mix of users - some who should be able to access the wiki, and some who shouldn't. Configuring the wiki authentication mechanism at the directory is simple - but it is an all or nothing proposition. And of course, we couldn't go change anything the directory itself.

Sounded like a job for OVD!

Here's the basic setup - OVD is deployed between our application and the main directory, like a proxy server. We want to OVD to effectively "filter" requests from the application.

Configuration of OVD is done using the OVD Manager client, which connects to the administration port of the OVD server.

Approach #1: DN Matching

If you can define the distinction between included/excluded entries in terms of an entry's DN, then a very simple solution is to use the "DN Matching" property of the source adapter. This is fund in the Routing configuration.

Say for example, we only wanted our OVD directory to include entries that are in the ou=ITGroup or ou=Management containers. In this case, we would set the DN Matching property with a regular expression that will match on the DN string:
m/(.*)ou=(ITGroup|Management)(.*)/


Approach #2: ACL Restrictions

In practice, the DN may not provide enough information to distinguish items to include and exclude, and it is necessary to discriminate on the basis of an attribute, such as "departmentName". In this case, access control in the OVD engine may be configured to restrict the directory view based on a suitable filter.
Filter: departmentName=ITGroup


It is important to note with this approach that ACLs can be applied to all LDAP operations, except bind.

As a result, the directory view we have created with OVD appears to only contain the filtered subset of information: we cannot browse, serach, get or modify anything else. However, if you present a fully-qualified DN and associated password, it will authenticate and bind any entry that exists in the source database.

On spec, that seems to blow the whole approach out of the water. That's what I was thinking too, until Mark Wilcox helpfully nudged me along with a neat insight...

If our requirement is to use OVD to restrict the set of users that can authenticate via an application, we only need to consider the application authentication mechanism. In most cases, the process is similar to the one illustrated below. The user enters an id or username, which is used by the application to lookup the user's DN, which is then used to bind along with the user-supplied password. If the application can't find the DN in the first place, then no bind is possible.

Of course, the acknowledged security "exposure" in this case is that a user can bypass the application and directly bind via OVD if they know their DN. However this is probably a false risk, because the user would have always had a similar capability with the source directory itself (assuming that the source directory and OVD are equally accessible to the user over the network).

Bottom line? Using ACLs to restrict the search effectively controls the set of users that the application can authenticate.

In Practice: Oracle WebCenter Wiki

Oracle WebCenter Wiki is thye example application, but you can think of it as any old J2EE application packaged as an EAR that supports Java SSO. By default it will use JAZN XML file-based storage for user accounts.

When deployed in OC4J, the security provider used for the Wiki application can be easily changed via the Enterprise Manager web interface.


Switching to OVD as the authentication source is a simple matter of selecting the Oracle Security Provider for 3rd Party LDAP Server and configuring it with some simple directory details:


Almost done. There are two assumptions that I think the wiki makes about the directory. Just need to make sure these are setup:
  • wiki users must be members of the group called "users"
  • administrators are members of the group called "oc4j-administrators"

Now you are done. The wiki authentication is being performed against the limited set of users visible through OVD.

Caveat: selecting the Oracle Security Provider for 3rd Party LDAP Server causes the site to revert to basic authentication (i.e. popup a username/password dialog instead of using a web form). Not a big deal, but you will find the "logout" feature in the wiki now fails because it assumes form-based custom authentication. So once you have people lured into your wiki, they are trapped! ;-)

Wrapping Up

I've covered two techniques for restricting the set of information published via OVD: DN Mapping, and ACL Filters.

There are other approaches that I've not covered here. For one, Java or Python plug-ins (a.k.a. mappings) can achieve the same result, as well as more complex behaviours of course.

These techniques allow OVD to be used to restrict overall access control for applications that use LDAP authentication mechanisms.

Once again, hat-tip to Mark Wilcox for his help when I thought I'd hit a wall while researching this topic!

Monday, January 07, 2008

Backup your WebCenter Wiki. Yikes!

Previously I wrote about installing Oracle WebCenter Wiki, and also had my 2c worth.

One of the surprises is that it uses file storage by default. Database storage seems to be a work-in-progress (Toplink, hibernate and HSQLDB are all involved somehow), but not a documented option at this point.

Now if you are going to run WebCenter Wiki for real, that means as a dilligent system admin you want to be pretty sure you really understand how the file storage is working so you can have good backup and recovery procedures in place.

The documentation on Backing Up and Restoring Wiki Content sounds straight-forward. Just make a backup of the OC4J_HOME/applications/application_name/owc_wiki/pages folder.

But BEWARE!

Gotcha #1: Don't Forget Your Toothbrush!
A little poking around, and it is clear that this is NOT all you need to backup. I've noted content modifications in at least the following locations also:
OC4J_HOME/applications/application_name/owc_wiki/attachments [any uploaded attachments]
OC4J_HOME/applications/application_name/owc_wiki/templates [added/changed page templates]
The jzwiki backup/restore instructions also tell you to backup WEB-INF/classes/yawikiDB.script (WebCenter wiki is based on jzwiki)

So to be sure you haven't left anything behind, I'd suggest you probably want to be backing up the entire OC4J_HOME/applications/application_name/owc_wiki directory structure no matter what the doc says, and practice some restores!

Gotcha #2: Beware of EAR Re-deployments!
If you've worked with OracleAS/OC4J deployment before, and also noticed that the wiki content is stored in the application directory structure, I hope it rang an alarm!

Yes, if you touch or replace the owc_wiki.ear, then say goodbye to your wiki content and pray your backup is good and not too old! OC4J will redeploy the application and give you a nice fresh install, deleting all your wiki content and customisations;-)

I have always had a sneaking suspicion that there can be other circumstances in which OracleAS/OC4J may choose to redeploy an EAR. I can't really substantiate this, but I have had situations in production where EARs are redeployed for no immediately apparent reason.

This is of course very hairy for any non-trivial production deployment. The obvious first step would be to configure wiki content storage to some other location. This isn't documented however, and I'm not sure if its even possible with the product as it is.

So for now, it seems just backup or rsync deep and often, and enjoy the view as you walk the edge of the abyss;-)

WebCenter Wiki Future?
So far, there's no real news on what is planned for WebCenter Wiki in 11g. If you've read my posts, it will come as no surprise that my view is the 10g wiki is far from production-ready.

Which makes the question of what is in store for 11g so interesting. Maybe a significant revamp of the 10g (jzwiki) wiki? Maybe an internally developed replacement based on Content DB or UCM?

Or maybe something completely different? A collegue pointed me to Jive Clearspace today .. "discussions, blogs, files, instant messaging, and wiki documents under one unified umbrella" .. and since Oracle already have Jive Forums integrated in WebCenter it raises interesting possibilities!

Monday, December 17, 2007

WebCenter - First Thoughts. WATCH/HOLD

I just posted about installing Oracle WebCenter Wiki. So what do I think?

The current release of Oracle WebCenter is 10.1.3, and presents the first attempt at providing a Web 2.0 platform incorporating a (development) framework, integrated Services, and mobility ("WebCenter Anywhere"). The roadmap for 11g emphasises features focused on improving a developer’s productivity.

Having spent a bit of time going beyond the powerpoints and whitepapers, I guess I would emphasise the "..first attempt.." in the statement above. There are concerns I have about the product mission, the egregious approach to Open Source project integration, and a work-in-progress information architecture. While I'll be closely following Oracle's progress with WebCenter, my personal view is that a cautious "watch/hold" position is prudent.

WebCenter as an out-of-the-box Web 2.0 Experience?


The first reactions to WebCenter typically concerned it's positioning with respect to Oracle Portal. After many repetitions, I think Oracle have managed to get the message through that there's a distinct value prop for Portal (classic, monolithic Enterprise Portal) and WebCenter (platform and services for a loosly-coupled "Web 2.0" user experience).

However when it comes to WebCenter itself, there's still tension in the 10.1.3 version between two very different audiences/usages it targets.

Firstly, there's the developer audience. There's great emphasis by Oracle on WebCenter as a development framework in the whitepapers and podcasts (e.g. a great interview between Justin and Vince Casarez on Oracle Fusion Middleware Radio).

Oracle WebCenter injects new capabilities into the standard JavaServer Faces development environment to allow developers to create context-rich applications that satisfy these needs.

The catch is that at present developers are well served with JDeveloper and associated developer downloads. WebCenter's attraction seems mainly as a licence bundle of pre-existing Oracle products like Secure Enterprise Search, Content Database and the Mobility Server. There's nothing very Web 2.0 about all that, except that taken altogether, developers certainly could build Web 2.0-style.

In a wild daydream, you may have hoped WebCenter would be to Java what Rails is to Ruby. An opinionated, highly productive, pre-integrated framework. For now I'm afraid you will be disappointed.

The second audience I refer to is the IT Operations/Business audience. These are the people who don't expect to be coding, but want a quick Web 2.0 jumpstart for their enterprise. They don't have the time or inclination to take on the job of investigating, integrating and maintaining a hodge-podge of all the possible open source options. Basically they just want to install it, and are happy to pay for the convenience.

In other words, hoping that WebCenter is to Web 2.0 out-of-the-box experience what Astaro is to security appliances. Again, I'm afraid you would be disappointed for now. The 11g roadmap does include an out-of-the-box application to enable self-service community creation and management.

I guess my problem at this point is that I'm not convinced that Oracle have really decided where to take this. The development focus is clear, but it is not clear at all how much will end up being "only available WebCenter" - one could easily imagine WebCenter ending up as just a licensing artifact, with all the framework technology also available separately. And on the other hand, I have real concerns over the commitment to WebCenter becoming a killer "Web 2.0 appliance".

Personally I think Oracle may have misjudged the market on this. Of the 20 or so people I have had casual WebCenter discussion with, all bar two were just after a blog/wiki/discussions platform to install. That's hardly representative, but I have a feeling Oracle would be more succesful in the market if they just focused on delivering the "appliance", with all the supporting framework rolled into the JDeveloper/OracleAS/ADF base.

As it seems to be going, I wouldn't mind betting the primary audience for WebCenter will turn out to be Oracle's own Fusion Applications development team, with most customers just adopting it as a result of their Applications investment.

Open Source Closure?


I am actually much more concerned about the approach Oracle have taken to integrate 3rd party open source components into the WebCenter Services layer.

Take the "standards-based, open-source wiki server that is included with Oracle WebCenter" for example (words from the 10.1.3.2 Technical whitepaper).

Oracle chose yawiki/jzwiki for their wiki component, and it certainly was (at least partially) an open source project. But in WebCenter, we seem to be dealing with a forked and closed source version. My concerns:
  • Oracle is not shipping source code for the Java classes in owc_wiki.ear

  • While some classes are available from the yawiki project, Oracle have made enhancements (I suspect the main cases being the controller to incorporate AdfAuthentiation; JSR-168 and WSRP portlet support). These are not provided as open source.

  • yawiki includes some packages (like jZonic-web.jar which contains the main controller framework) which are purportedly open source, but for which there seems to be no source code available on the Internet [Postscript: I take this back having since discovered that the source of jzonic-web.jar is from the femto module in the jZonic framework]

  • The version of the wiki in WebCenter has been forked from yawiki. There is no procedure provided to merge the yawiki main line. WebCenter wiki users seem to be completely dependent on Oracle to merge enhancements in yawiki into WebCenter updates. Or not.

  • There are already enhancements in yawiki that are not available in WebCenter (e.g. TagClouds, RSS feeds of page changes). And no procedure for adopting these enhancements.

  • The WebCenter wiki seems to only be supporting the file-based HSQLDB (see backup/restore procedures for example), despite the fact that yawiki has or promised relational database support - even Oracle!

  • Despite the customisation that Oracle have done to yawiki, there's currently no integration the content database component in WebCenter for content storage or tagging.

So I guess you could say I was underwhelmed. From a practical perspective of a wiki implementer, there seems to be little upside in chosing to go with WebCenter wiki over its true open source father, yawiki, or others such as xwiki. But some big downsides to consider.

I'd much prefer see Oracle take a very different tack with the integration of "open source" components into WebCenter.

  • Ship mainline version of the open source project (don't close the source)

  • Provide Oracle enhancements (for security integration etc) as patches to the open source project. Do not combine a version of the open source project with Oracle-written customisations, and ship as "closed source".

  • Where possible, contribute the "WebCenter" patch to the open source project so that it can be maintained in sync with that project.

  • Ideally, reach as many projects in the same category as possible (i.e. support a few different wikis in WebCenter). A great way to do this would be to encourage the community to do it themselves. Yawiki is OK, but there are certainly some great alternatives out there.

Wherefore art thou, my blog?


The WebCenter whitepapers repeatedly mention phrases like "key technologies such as wiki, RSS, and blogs". The Datasheet still specifically claims WebCenter has a "wiki/blog server for collaborative authoring of documents and sharing of ideas".

Wiki - got, despite concerns already discussed. RSS - some, but not in all places that it counts (like the wiki!). But blog? It's MIA!

I have a sneaking suspicion that this is because yawiki used to have a blog capability, but the project team wanted to rethink the approach and dropped it. It is now in the planned feature list;-)

OK, these things happen. But in the WebCenter 11g roadmap, Oracle seem to have defined blogs out of existence - at least in terms of their relevance for the "Enterprise"! Was this to gloss over the missing blog feature in yawiki? Or is there a real belief that blogging is not part of the Enterprise 2.0 model? I'm not sure which view concerns me most!

Blog? blog? Where's the blog support?

It is even more curious when you consider (as Bex Huff recently reminded us) Oracle Universal Content Management has Blogs, Wikis, and RSS Feeds. And the roadmap for WebCenter 11g has UCM replacing Content DB.

Conclusions?


I've presented some pretty frank views on WebCenter after my "first look". Take my comments with a grain of salt though. I have not investigated the framework developer experience in detail yet. But I would say that Oracle has a lot riding on the 11g release. I hope they make it a more "opinionated" and cohesive release and get to knock down some of my concerns.

Sunday, December 16, 2007

WebCenter Wiki - Up and Running with OC4J 10.1.3

I finally had a chance to sit down with Oracle WebCenter recently, primarily to give the wiki functionality a test drive. I wanted to test in a virgin OC4J 10.1.3.3 container (as opposed to the Preconfigured Standalone OC4J) just to make it interesting and see all the moving parts. As far as I could discover, there's not a great deal of information available on the topic. In this post I'm going to chronical the specific installation procedure I used to get WebCenter Wiki running under OCJ4 10.1.3.3.

This is the end result we're after..


Documentation and Downloads

The documentation for WebCenter Wiki is a little obscure when it comes to installing in a "plain" OC4J container. It turns out to be pretty straight-forward, but just as mc said in the forums recently: "Oracle documentation just make it look difficult"!

I refered to the following materials for the install:

It can all get a bit confusing, but the following diagram illustrates the installation dependencies

There are four downloads required, all readily available from OTN:

Installation Procedure


I'm going to document the install steps here in the order I actually executed them. Variations are possible. I'm installing this under Windows XP, but the same applies on other platforms (just switch \ to / and use the appropriate command shell syntax).

1. Get the OC4J container running
To be precise, I am using "Oracle Containers for J2EE (OC4J) 10g Release 3 (10.1.3.3)". I won't cover in detail here. Basically you need to unpack and startup. The only thing you may need to configure are the port settings to avoid conflicts with other services.

2. Install PDK-Java
Details for installing the Oracle Portlet Development Kit are in index.html from the Oracle Portlet Container and PDK-Java 10.1.3.2 download. Assuming we've exploded the download into "G:\pdksoftware", the following performs the installation into the 10.1.3.3 home:

set ORACLE_HOME=G:\MyCache\oc4j_extended_101330
set J2EE_HOME=%ORACLE_HOME%\j2ee\home
set JAVA_HOME=C:\bin\jdk1.6.0_03
set PDKPATH=G:\pdksoftware
%JAVA_HOME%\bin\java -jar -classpath %ORACLE_HOME%\lib\xmlparserv2.jar -jar %PDKPATH%\pdk\jpdk\v2\pdkinstaller.jar %J2EE_HOME%


3. Install the Portal Container
From the same kit, we install the Portlet container

set ORACLE_HOME=G:\MyCache\oc4j_extended_101330
set J2EE_HOME=%ORACLE_HOME%\j2ee\home
set JAVA_HOME=C:\bin\jdk1.6.0_03
set PDKPATH=G:\pdksoftware
%JAVA_HOME%\bin\java -jar %PDKPATH%\pdk\portlet-container\portlet-server-install.jar %J2EE_HOME%


4. Install and Test the Sample Portlets
Using Enterprise Manager (http://localhost:8888/em or similar), go to the "Applications" tab and deploy the %PDKPATH%\pdk\jpdk\v2\jpdk.ear.

Once done, you should be able to successfully access the sample providers at http://localhost:8888/jpdk/providers/sample and get a page like the one shown on the right.

5. Install ADF
Explode the Oracle ADF Installer, which uses a silent "runInstaller" to install.

First, you'll need to update the adfinstaller.properties file, paying particular attention to OracleHome, DesHome and type values. This is from my install:

# The absolute path to the directory containing the ADF jars to be installed.
# This is the location of the directory where you unzipped the adfinsatller.zip
OracleHome = G:\\Sources\\incoming\\www.oracle.com\\OracleAS\\ADF\\adfinstaller

# Home directory for the destination application server,
# where the ADF Jars need to be installed
DesHome = G:\\MyCache\\oc4j_extended_101330

# Specify the platform for the Application Server where the ADF libraries need
# to be installed. This has to be one of the following choices.
# OC4J/AS/TOMCAT/JBOSS/WEBLOGIC
type = OC4J

And then run:
java -jar runinstaller.jar adfinstaller.properties

Restart OC4J at this point.

BUT, if you were like me, my container failed to start at this point with Error initializing server: Shared library "adf.oracle.domain" could not be found..

Annoying, but no panic. Edit ORACLE_HOME/j2ee/home/config/server.xml, re-order the shared library entry for "adf.oracle.domain" (I moved it to just after the "oracle.persistence" shared library) and try to startup again.

NB: after getting to this point, I find my OC4J does not completely shutdown after issuing a shutdown request via RMI %ORACLE_HOME%\bin\oc4j -shutdown -port %RMIPORT% -password %adminpwd%. Leaving that problem for another day.. :sigh:

6. Install Oracle Wiki (finally)
Using Enterprise Manager (http://localhost:8888/em or similar), deploy the owc_wiki.ear from the Oracle WebCenter Additional Services CD

7. Configuring Security
If you try and hit the wiki now (http://localhost:8888/owc_wiki) you will probably get a 500 error because security is not started or configured.

For this test, I'm just going to use the out-of-the-box Java SSO File-Based Security Provider.

In EM, startup the Java SSO application (look under the application group "Middleware Services > Other Services"). If you try and access the wiki now, you should see a login form but get an error when you submit because we need to generate the Symmetric Key. Every time I go to do this, following the Java SSO documentation, I struggle to find the right link in EM.

To be clear, in 10.1.3 look for "SSO Configuration" on the Administration tab of the OC4J container (below). Go to the page, make sure "Generate new symmetric key" is checked, select your key type, and click "Apply". You will be prompted to restart OC4J.


Browse to the wiki again and we have .. Success!


8. Adding users
Remember we're using the JAZN XML security provider rather than OID or other directory. Andreas had a nice post recently on how to Add a user to the JavaSSO, and that's what I need to do to add a personal account for myself..

set ORACLE_HOME=G:\MyCache\oc4j_extended_101330
set J2EE_HOME=%ORACLE_HOME%\j2ee\home
set JAVA_HOME=C:\bin\jdk1.6.0_03

%JAVA_HOME%\bin\java -jar %J2EE_HOME%\jazn.jar -adduser jazn.com paul password1
%JAVA_HOME%\bin\java -jar %J2EE_HOME%\jazn.jar -grantrole users jazn.com paul

JAZN is a bit dumb compared to using a real directory, so you need to restart OC4J again to pick up the new credentials.


And there we go. Oracle Wiki up and running in OC4J. Just 8 "simple" steps;-)