Deploying the ALBPM Workspace into WebLogic Portal

Customers that purchase both WebLogic Portal (WLP) and AquaLogic Business Process Management (ALBPM) will certainly want them to work together. Specifically, customers want to be able to deploy the ALBPM Workspace user interface as portlets on a WLP portal. This blog explains how to do that, and provides a script to help automate the most tedious steps.

NOTE: this blog entry was originally posted December 17th, 2007 on my previous blogging system (dev2dev.bea.com).

Use Case

The ALBPM Workspace contains a total of 4 portlets. By default, they deploy in their own pre-built web application. But if you have both ALBPM and WLP in your environment, it would be useful to be able to deploy the portlets into WLP.

The four portlets are:

• Actions Menu: lists the operations the user can perform, like create a new process
• Views Menu: lists the various views available, like process inbox and bookmarks
• Worklist: displays the list as directed by the Views menu, like the list of active processes
• Instance Detail: shows the details of a specific process

A view of the completed Workspace on WLP:

Integration Implementation

Behind the scenes, there are some challenges to this project. First, when the user authenticates with WLP, they shouldn't have to also sign into ALBPM. Fortunately, ALBPM implemented an SSO mechanism in ALBPM 6.0. This can be enabled via a couple of checkboxes during the configuration of ALBPM (more on this later).

Second, the portlets and all supporting file based artifacts need to be brought into the WLP Web Project. While most of this is straightforward, it is an error prone operation. Also, merging in the necessary web.xml entries for the ALBPM workspace into the stock WLP web.xml is tricky. A simple error can create headaches. This part screams for an automated solution.

To make this integration as easy as possible, I have created a distribution that contains movies and an Ant script. The movies will to help guide you through the process. The Ant script removes a lot of tedious steps from the process.

Note: while this integration guide and script are deemed reliable, they are not officially supported. The official documentation is the supported source of information on this integration.

ALBPM 6.0 Workspace for WLP 10

There is official documentation to explain how to integrate the products. But sometimes seeing the integration is the best teacher. Therefore, the distribution that I have created includes a series of movies. Additionally, it contains an overview presentation on the process of integrating the products. Finally, the actual deployment of the ALBPM Workspace onto WLP is scripted via an Ant script that I provide.

I have hosted the files of the distribution in this location:

ALBPM 6.0 Workspace for WLP 10 Download Center

Note: to view the Flash FLV movies you will need an FLV player, such as the free FLVPlayer

ALBPM_for_WLP_slides.zip and ALBPM_for_WLP_slides_movie.zip

Start with these. One zip contains the Powerpoint presentation, the other contains a movie of me talking through the slides. This deck explains what the integration is all about, and the high level steps needed to perform the integration.

ALBPM_for_WLP_movie1.zip, ALBPM_for_WLP_movie2.zip, ALBPM_for_WLP_movie3.zip

These zip files contain detailed walk throughs of various parts of the integration. View these movies in order, and use the Pause button so you can follow along while you perform the integration on your machine.

ALBPM_for_WLP_script.zip

This zip contains the Ant script and associated files that will automate the ALBPM Workspace deployment into WLP. This script does a ton of file copying and also includes some new files (.portlets) to make this a smooth process. While you can do all of this by hand, the script gets the job done quickly and correctly.

Acknowledgements

I didn't complete this project by myself. The ALBPM Development and QA teams (Eduardo, Nico, Mariana, Alex, Mariano, and others) did a lot of work on sorting out the process to get the products integrated. Additionally, some folks from BEA Professional Services (Paddy in particular) helped get this going. THANKS!

Additional Resources

Need more information? Here are some good links to get you started:

• WLP Download - download WebLogic Portal (minimum version 10.0)
• ALBPM Download - download AquaLogic BPM (minimum version 6.0 MP1)
• ALBPM for WLP Official Documentation - official docs for integrating the products
• Alex Toussaint's Blog - ALBPM product manager's blog
• Jesper Joergensen's Blog - ALBPM product marketing blog
• Josh Lannin's Blog - WLP products manager's blog, check out the 5 part WLP futures series

Technorati Tags: weblogicportal,albpm

Comments from the original blog:

• Hi Praveen -

  Yes, something with the Apache config is doing strange things with that. We just did a lot of Apache work to speed up the WLP demos, and I am nervous to touch it to sort out the issue. I have found that Firefox, not IE, should be able to download the files fine. Can you try that?

  PJL

  Posted by: plaird on May 5, 2008 at 11:16 AM

• Peter, thanks a lot. It seems like a very useful information but I am not able to download using the hyperlinks. Can you pls help me in getting these? my emailID: awasthypr@saic.com Thanks again!!

  Posted by: praveenawasthy on May 5, 2008 at 2:15 AM

• ALBPM 6.0 MP2 Update

  I produced the script and movies against ALBPM 6.0 MP1. However, I tested against 6.0 MP2 with success (with one caveat).

  The only issue is that there are some JSPs in the ALBPM MP2 workspace that cause the Workshop IDE (WLW) to report build failures (about 45). You will need to disable JSP validation for the WLP web project to get around this.

  Project Properties->Validation->uncheck the JSP validator

  I have updated the presentation to include this GOTCHA, and will also work with the ALBPM team to discover the root cause.

  Thank you Neville for reporting the issue.

  PJL

  Posted by: plaird on January 8, 2008 at 9:31 AM

• Kunai -

  Sorry about that, I was using an 3rd party file share to host the files. I have rehosted the files on our WLP demo server at wlp.bea.com. I updated the link in the blog too.

  Thanks for the note!

  Posted by: plaird on January 3, 2008 at 11:35 AM

• Peter, I'm about to get started on deploying ALBPM Workspace on WLP and I would've loved to have downloaded your slides, movies on the subject. However, it appears that the hyperlinks for these downloads have been disabled. Is there any other way we can exchange this information? Please feel free to send an email at "kunal.r.shah@citi.com" Regards, Kunal R Shah

  Posted by: kunalrshah on January 3, 2008 at 11:07 AM

Want short SaaS/Cloud news updates throughout your day? Subscribe to the ondemand Twitter microfeed. http://twitter.com/ondemand

AquaLogic Commerce Services 5.1 for BEA Workshop 9.2

BEA released AquaLogic Commerce Services this year to help BEA customers with their commerce initatives. ALCS is a product that offers a storefront and comprehensive merchandising capabilities out of the box. If you need to build a commerce solution for your business, ALCS makes it quick and easy. This blog entry describes a supplemental distribution that allows BEA Workshop developers to get up and running easily on ALCS.

NOTE: this blog entry was originally posted October 18th, 2007 on my previous blogging system (dev2dev.bea.com).

NOTE: as of 2009, the ALCS product has been discontinued.

AquaLogic Commerce Services

This blog entry will not focus on the ALCS product itself, but if you have not seen it here is a quick overview. It is a full solution for developing commerce projects for the enterprise. ALCS provides a fully customizable commerce solution that offers many features for both developers and merchandisers.

Features at a Glance

• Complete storefront delivered in the box - a powerful web shopping experience
• Merchant Tools - catalog management, promotion management, analytics
• CSR Tools - order management, fulfillment
• SEO - world class SEO capabilities to drive customers to your door step
• Ajax one page checkout - fast track your customers through the checkout process
• Developer friendly - productive development experience based on Velocity and Spring MVC technologies
• Extensibility - highly customizable and extensible architecture offers complete control over the solution
• SOA foundation - features exposed via web services, and integrated into the BEA SOA story
• Scalability - built on enterprise Java technology, ALCS can scale to meet the demands of the largest commerce projects

For more detailed information on the features in the product, please check out the product information page.

Introducing ALCS 5.1 for WLW 9.2

One of the benefits of ALCS for BEA customers is that it deploys to WebLogic Server and integrates with WebLogic Portal. It fits in with the products that you already know and love. This makes deployment consistent with other projects you have deployed on the WebLogic stack.

However, for the ALCS 5.1 release the development environment out of the box is not aligned with the BEA Workshop IDE. This will get sorted out for the next release of ALCS. Until then, I have created a supplemental solution for ALCS 5.1 that allows for easy integration with BEA Workshop 9.2.

Called ALCS 5.1 for WLW 9.2, the supplemental download has the following features:

• Script target to reprovision the ALCS sample application into the Workshop project structure (aka WTP)
• Script target to reskin the sample store from "Snap it Up" to "Avitek Digital" (credit to Dan Tortorici!)
• Script target to add in prominent disclaimer/promotion announcements to the store

The download available on dev2dev CodeShare includes ample instructions and a presentation that provides more context.

 DOWNLOAD ALCS 5.1 for WLW 9.2

Additional Resources

To get started with ALCS, also consult the following documentation:

• ALCS Product Documentation: top level link to the ALCS technical documentation
• Developers Guide: a comprehensive developers guide
• ACLS 5.1 Download: link to download a free evaluation of ALCS
• ALCS Marketing Center: materials to help convince your boss to use ALCS
• Wendy Bales' blog: great thoughts from the ALCS product manager

Technorati Tags: WebLogic,AquaLogic Commerce,ALCS,Workshop

Want short SaaS/Cloud news updates throughout your day? Subscribe to the ondemand Twitter microfeed. http://twitter.com/ondemand

WebLogic Security: Configuring the Database Authentication Providers (SQL, Custom, DBMS)

I have gotten a lot of WebLogic security related questions offline as a result of my last blog post. A couple of people have asked for more details behind the WebLogic SQL Authenticator (a database authentication provider) that I mentioned. This blog entry will give deep background into your options when it comes to authenticating users from a database repository. I will finish by explaining how to configure the SQL Authenticator.

NOTE: this blog entry was originally posted September 25th, 2007 on my previous blogging system (dev2dev.bea.com).

First, a bit of terminology. When looking in the WebLogic Server documentation for a database authentication provider you will find at least a few names:

• Database Base Management System (DBMS) authentication providers
• SQL Authenticator
• SQL Authentication provider
• RDBMS Authentication providers
• Read-only SQL Authentication provider
• Custom DBMS Authentication provider

We all love choice, but what's up with all these names? Are they all the same thing, or does WLS provide multiple provider implementations?

In short, WebLogic does provide multiple database authentication provider implementations. This blog entry will sort out specifically what providers are available to you when authenticating from a database. We will look inside the WebLogic providers to understand what features are supported by which provider. After we have that covered, I will describe how to configure a SQL Authenticator provider in the WLS Console and how to provision the database.

Peter's Best Practice: Use a Database Backed Authentication Provider!

Before we dive into the details, I want to take a moment to congratulate you on reading more about this topic. I have worked at BEA many years, and I have been involved in many customer production escalations. When it comes to Authentication repositories, my experience tells me that you are safest performance-wise with a database backed authentication store. While customers have certainly been successful with other types of authentication repositories, if you want to minimize risk the database approach trumps all others. A database backed repository has few moving parts, and the query necessary to authenticate a user is a simple SELECT. So if you want my opinion, I say go with a database when you have the option.

The Official Flavors of WebLogic Database Authentication Providers

Back to the topic at hand - what are the WebLogic database authentication providers? The official documentation source, edocs.bea.com, will get us started. The docs explain what is provided for you:

Weblogic Security Providers

A set of Database Management System (DBMS) authentication providers that access user, password, group, and group membership information stored in databases for authentication purposes. Optionally, WebLogic Server can be used to manage the user, password, group, and group membership information. The DBMS Authentication providers are the upgrade path from the RDBMS security realm. The following DBMS Authentication providers are available:

• SQL Authentication provider - A manageable authentication provider that supports the listing and editing of user, password, group, and group membership information.
• Read-only SQL Authentication provider - An authentication provider that supports authentication of users in a database and the listing of the contents of the database through the WebLogic Server Administration Console. The authentication provider requires a specific set of SQL statements so it might not meet all customer needs.
• Custom DBMS Authentication provider - A run-time authentication provider that only supports authentication. This provider require customer-written code that handles querying the database to obtain authentication information.This authentication provider is a flexible alternative that allows customer to adapt a DBMS Authentication provider to meet their special database needs.

The documentation is reflected by the WebLogic Console, which provides the following dropdown of authentication providers to choose from. Notice that the three database authentication provider types appear.

While the above descriptions provide some information about the difference between these providers, we can do better. Because you are a developer, you probably want the inside story. Today is your lucky day!

Inside the WebLogic Database Authentication Providers

To get the inside story let's head straight for the source - the authentication provider configuration files. You will find them here:

• BEA_HOME/WL_HOME/server/lib/mbeantypes/cssWlSecurityProviders.jar

If you open up this JAR, you will find 4 files of interest: DBMSAuthenticator.xml, CustomDBMSAuthenticator.xml, ReadOnlySQLAuthenticator.xml, and SQLAuthenticator.xml. Three of those map directly to the official authentication provider implementations, so those are obviously their configuration files. The fourth, DBMSAuthenticator - what is that? If you look into the XML files, you find that DBMSAuthenticator is the base class for the rest of the providers. By looking at the Extends attribute on the MBeanType element, you can derive the class hieararchy of the providers, shown below.

Now that you understand how the providers are related, how do you know which one you want? WLS/CSS authentication providers have two components - the JAAS code that actually performs the authentication at runtime, and then a set of management "mbeans" that the provider chooses to implement. Every management feature that a provider can support is surfaced as an mbean interface. The key to understanding what a provider can do for you is to look at the mbean interfaces that it implements. Each interface is optional, meaning a provider may choose what features it can support.

Here is the list of mbeans for authentication providers which provide the manageability around users and groups:

SSPI MBean Quick Reference

• GroupReader Read data about groups.
• GroupMemberLister List a group's members.
• MemberGroupLister List the groups containing a user or a group.
• UserReader Read data about users.
• UserPasswordEditor Change a user's password.
• GroupEditor Create a group. If the group already exists, an exception is thrown.
• GroupRemover Remove groups.
• UserEditor Create, edit and remove users.
• UserRemover Remove users.

Mapping out our providers into a table and the mbeans they implement shows the vast difference in manageability. You will want to select a provider based on your requirements for managing users and groups from WLS.

Using the CustomDBMSAuthenticator

This provider is obviously not for use in situations when manageability from WLS is important. It offers no management support. What it does offer is a lowest common denominator approach to integrating a database user repository. Employ this provider when you need to surface just authentication capabilities to WLS, and nothing else. You simply need to implement a plugin that answers the most basic of questions.

• CustomDBMSAuthenticatorPlugin Javadoc - explains what needs to be implemented
• Sample CustomDBMSAuthenticator provider - the MedRecDBMSPlugin from the MedRec sample (found in your install at BEA_HOME/WL_HOME/samples/server/medrec/src/security/com/bea/medrec/security)

Configuring the SQL Authenticator

You are more likely to be using the Read-only SQL Authentication provider or the most powerful SQL Authentication provider. These providers give you manageability from the WLS Console (and WLP Console if using WLP). They are easy to instantiate - the UI surfaces the options you need to configure. I won't go into all the options, but it is important to see that you can change the SQL for each operation if you have a custom schema. The SQL for these providers is designed to be modified to allow you to retrofit a custom database schema. But you can also use the default schema if you are provisioning a brand new user repository (see below for the schema).

After configuring the provider, any deltas versus the defaults will be persisted into config.xml. You can see below, I updated the Datasource of course (this is required) but I also made an arbitrary change to the Create Group SQL. See how it wrote the update into config.xml.

<sec:authentication-provider xsi:type="wls:sql-authenticatorType">
  <sec:control-flag>
    SUFFICIENT
  </sec:control-flag>
  <wls:enable-group-membership-lookup-hierarchy-caching>
    false
  </wls:enable-group-membership-lookup-hierarchy-caching>
  <wls:data-source-name>
    p13nDataSource
  </wls:data-source-name>
  <wls:sql-create-group>
    INSERT INTO GROUPS VALUES ( 'arbitrary change' , ? )
  </wls:sql-create-group>
</sec:authentication-provider>

The Default Schema DDL for the SQL Authenticator

You can define whatever schema you want to store users and groups when using the SQL Authenticators. But if you are starting fresh, why not just use the default schema and the default settings on the provider. I would highly recommend this approach.

It doesn't look like we officially document the default database schema so let me show you what it is. I list the Oracle DDL below, but you can find the official DDL for your database vendor in the following location in the WLS 10 install (and a similar location for other versions):

• BEA_HOME/wlserver_10.0/common/p13n/db/DB_VENDOR/p13n9_create_tables.sql
  
  

CREATE TABLE USERS (
    U_NAME VARCHAR(200) NOT NULL,
    U_PASSWORD VARCHAR(50) NOT NULL,
    U_DESCRIPTION VARCHAR(1000))
;
ALTER TABLE USERS
   ADD CONSTRAINT PK_USERS
   PRIMARY KEY (U_NAME)
;
CREATE TABLE GROUPS (
    G_NAME VARCHAR(200) NOT NULL,
    G_DESCRIPTION VARCHAR(1000) NULL)
;
ALTER TABLE GROUPS
   ADD CONSTRAINT PK_GROUPS
   PRIMARY KEY (G_NAME)
;
CREATE TABLE GROUPMEMBERS (
    G_NAME VARCHAR(200) NOT NULL,
    G_MEMBER VARCHAR(200) NOT NULL)
;
ALTER TABLE GROUPMEMBERS
   ADD CONSTRAINT PK_GROUPMEMS
   PRIMARY KEY (
      G_NAME, 
      G_MEMBER
   )
;
ALTER TABLE GROUPMEMBERS
   ADD CONSTRAINT FK1_GROUPMEMBERS
   FOREIGN KEY ( G_NAME )
   REFERENCES GROUPS (G_NAME)
   ON DELETE CASCADE
;

A Few Details for WebLogic Portal Customers

This thread got started because I was discussing in my last blog how WLP 9.2+ by default uses the WebLogic SQL Authenticator. You can, of course, add more authentication providers and remove the SQL Authenticator if you like. When installing WLP, the installer (or you can use the createdb script) will lay down the default SQL Authenticator schema into the WLP schema. Therefore, by default, WLP uses just a single schema for both authentication and Portal operations. This is the most convenient option, but you can change this by switching out the configured datasource.

More Information

For further reading, I suggest these links:

• Security Fundamentals - official WebLogic security primer
  
  
  
  
  
  



• WebLogic Server SSPI - the CSS security architecture
  
  
  
  
  
  



• SSPI Provider Samples - reading aboout the SSPI is good, but coding is even better. Try building your own ATN provider.
  
  
  
  
  
  



• Foundations of WLP Security - official doc about how WLP integrates into WLS Security
  
  
  
  
  
  



• Implementing SSO with the WLS SSPI - my dev2dev blog on SSO with Identity Asserters
  
  
  
  
  
  



• JAAS Fundamantals - a dev2dev article by Bill Kemp and Rich Helton
  
  
  

Technorati Tags: J2EE,WebLogic,Security,Authentication,SQLAuthenticator

Comments from the original blog:

• 
  
  
  
  

  Great article! I was able to successfully help my client configure one for their needs. Thanks again.

  
  
  
  
  
  
  
  
  

  Posted by: sghattu on November 11, 2007 at 6:57 PM

  
  
  
  
  
  
  

• 
  
  
  
  
  
  
  
  

  I just got a question offline that I will record here - the developer was having trouble creating an Ant build script for building a custom Atn provider.

  
  
  
  
  
  
  
  
  

  My answer:

  
  
  
  
  
  
  
  
  

  When building providers, I have always used the Sample SSPI download from dev2dev CodeShare. It contains a working build script so all of this is taken care of for you.

  
  
  
  
  
  
  
  
  

  SSPI Code Sample

  
  
  
  
  
  
  
  
  

  Posted by: plaird on October 19, 2007 at 10:21 AM

  
  
  
  
  
  
  

• 
  
  
  
  
  
  
  
  

  Hi Peter, Interesting post but I would like to get more details on your SQLAuthenticator console configuration screenshot. Could you provide me more details on the DataSource name you use. I'm running into troubles with that part! I've tried to provide a configured JDBC data source name but this does not work as the DS is not yet initialized when the security is initialized (not able to start the console anymore). I've tried to provide a Data Source Factory name also without any success!! (Can start the console, but error in the log saying: Connection Pool not usable) Any idea? I'm using Oracle 10g thin jdbc driver and WebLogic server 9.2 Thanks in advance Daniel

  
  
  
  
  
  
  
  
  

  Posted by: ni2corp on September 25, 2007 at 11:43 PM

  
  
  
  
  
  
  

Want short SaaS/Cloud news updates throughout your day? Subscribe to the ondemand Twitter microfeed. http://twitter.com/ondemand

Discussion on WebLogic Security: Authentication Providers, Internal LDAP, JAAS, WebLogic Portal, Profile

This blog entry comes from an email thread I had with a fellow BEA colleague. We traded a number of emails - he asked a lot of great questions about how WebLogic Portal (WLP) supports various security features. Since WLP relies heavily on WebLogic Server for those features, my answers apply to WebLogic in general and not just Portal. I am posting the email thread here because I think that this discussion might be of interest to others.

NOTE: this blog entry was originally posted September 22nd, 2007 on my previous blogging system (dev2dev.bea.com).

Before I show the thread, I should provide a glossary of abbreviations and concepts:

• WLS: WebLogic Server, the J2EE application server that most people associate with the name "WebLogic"
• WLP: WebLogic Portal, the J2EE portal product built on top of WLS
• CSS: in this context, not cascading style sheets. Common Security Service is the componentized security package that WLS uses for security.
• SSPI: the pluggable security subsystem provided by CSS to WLS
• ATN: authentication, which refers to the process of verifying who a user is (with a password perhaps)
• ATZ: authorization, which refers to the process of deciding whether the authenticated user has the privilege to perform a certain action
• UUP: a WLP feature that aggregates profile information for a user from a variety of backend sources using a plugin architecture
• Internal LDAP: an LDAP repository embedded in CSS historically used for some default SSPI providers

Discussion Thread

From: Colleague

Quick follow-up to our discussion in the hall at BEAWorld, you said that WLP wants to stop using the internal LDAP server altogether and use the database instead. I forgot, though, did you say that had already happened in a previous release, or is that slated for the next release?

From: PJL

Yes and no.

For ATN, WLP does not use internal LDAP. WLP switched to the WLS/CSS provided SQLAuthenticator in WLP 9.2. This does not mean that customers must use it, it is merely the default. A customer may choose to toss the SQL ATN provider and plug in an LDAP, Active Directory, etc. provider instead.

Here is the WLS doc reference to SQL Authenticator: Configuring RDBMS Authentication Providers

As for ATZ (WLP entitlements and delegated administration), we rely on the default ATZ provider from WLS, which in turn uses the internal LDAP store. Currently, we are tightly bound to the default ATZ provider for various reasons, and so WLP therefore has a hard dependency on internal LDAP. This is not ideal, and so WLP wants to eliminate the internal LDAP dependency.

The forthcoming solution to this problem is for WLS to support a database as the backend store for the default ATZ provider. They should have this in the next WLS version (but no promises folks!), and so we will pick it up in a future release beyond Flatirons (the next WLP release).

From: Colleague

Right, makes sense. A couple more questions:

Can customers configure more than one ATN provider, e.g. extranet users in SQL and employees in Active Directory, is that a supported WLP configuration?

Do documents stored in WLP's virtual content repository (VCR) use the default ATZ provider as well?

Where does the Unified User Profile (UUP) fit into this picture?

From: PJL

>> Can customers configure more than one ATN provider, e.g. extranet users in SQL and employees in AD, is that a supported WLP configuration?
Yes, and you can do logic like AND and OR via the JAAS control flags (this is WLS/CSS doing that, not WLP).

>> Do documents stored in WLP's virtual content repository (VCR) use the default ATZ provider as well?
Yes, Entitlements defined on VCR documents are stored in the default ATZ provider. The documents and metadata themselves are in the WLP database if the BEA Repo is being used, or in third party systems like Documentum or Sharepoint.

>> Where does the Unified User Profile (UUP) fit into this picture?
Profile is the third leg to this: ATN, ATZ, and Profile. For WLP, all three are independent, and linked together just by username. So ATN could come from Active Directory, whereas profile can be aggregated from, for example, a mainframe, LDAP, and Siebel via UUP. WLP passes the UUP plugins the username that was authenticated, and then each plugin is responsible for retrieving the correct profile info.

From: Colleague

One piece I'm still a bit fuzzy on is how groups fit into this whole picture, I've been reading this section on edocs:

Adding and Managing Groups (WLP docs)

It sounds like WLP periodically syncs group info from the providers into some local store, which I'm guessing is the default RDBMS. Is that correct?

From: PJL

Good question.

Actually WLP doesn't really maintain its own group mapping. The ATN providers provided by WLS are responsible for doing that. We do some caching of the group tree because it can be expensive to build, so that is what those docs are talking about. But we don't write that in-memory cached tree out to the database or file system.

To see how an ATN provider is involved in group membership, look at how the SQL Authenticator gets configured as an example:

SQL Authenticator Configuration help

You can see that it has methods for managing group relationships. How this happens at runtime is a deeper dive into the WLS/CSS SSPI ...

WLS/CSS authentication providers have two components - the JAAS code that actually performs the authentication, and then a set of "mbeans" that the provider chooses to implement. Most of the mbeans are optional to implement. Here is the list for ATN providers which provide the manageability around users and groups:

SSPI MBean Quick Reference

• GroupEditor Create a group. If the group already exists, an exception is thrown.
• GroupMemberLister List a group's members.
• GroupReader Read data about groups.
• GroupRemover Remove groups.
• MemberGroupLister List the groups containing a user or a group.
• UserEditor Create, edit and remove users.
• UserPasswordEditor Change a user's password.
• UserReader Read data about users.
• UserRemover Remove users.

So WLP uses methods from the GroupReader and GroupMemberListers mbeans on the ATN provider to have access to group membership. The SQL Authenticator implements the GroupReader and GroupMemberLister mbeans by using those SQL queries. The LDAP ATN provider GroupReader and GroupMemberLister mbeans derives Group structure from the directory structure.

That's a little abstract - it sometimes helps to see the code. Here is the javadoc for GroupReader and GroupMemberLister java interfaces that the ATN providers implement:

• GroupReader javadoc link
• GroupMemberLister javadoc link

So WLP is not really managing it's own group repository, it's the ATN Providers that are storing that information. A little complicated, I know.

From: Colleague

So does the LDAP ATN provider support the GroupEditor as well? That is, can you write group membership changes back into external LDAP repositories?

From: PJL

The LDAP ATN provider that WLS/CSS provides is read only. You can see what mbeans it implements by looking here:

1. Navigate to BEA-HOME\wlserver_10.0\server\lib\mbeantypes
2. Open cssWlSecurityProviders.jar
3. Find the .xml file that is associated with the provider you care about, in this case LDAPAuthenticator.xml
4. In that xml file, you will see the mbean interfaces that it implements listed:

<MBeanType

 Name          = "LDAPAuthenticator"

 DisplayName   = "LDAPAuthenticator"

 Package       = 
   "weblogic.security.providers.authentication"

 Extends       = 
   "weblogic.security.providers.authentication.LoginExceptionPropagator"

 Implements    = 
   "weblogic.management.utils.LDAPServer,
    weblogic.management.security.authentication.UserReader,
    weblogic.management.security.authentication.GroupReader,
    weblogic.management.security.authentication.GroupMemberLister,
    weblogic.management.security.authentication.MemberGroupLister,
    weblogic.management.security.authentication.UserPasswordEditor,
    weblogic.management.security.authentication.GroupMembershipHierarchyCache"

 PersistPolicy = "OnUpdate"
> 

Since it does not include GroupEditor or UserEditor, you can infer that it is a read-only provider (aside from password). If you are a WLP customer, another way to see which mbeans are implemented for each ATN provider is through the Portal Administrator tool (PAT). Because the PAT disables certain user/group management functions in the tool depending on what mbeans are implemented on the selected provider, the PAT provides UI to show which mbeans are implemented. See the image below:

From: Colleague

Also, is there any way to create a group that includes members from more than one provider, e.g. "John" from the DB and "Bob" from LDAP? Or do you need to use roles for that scenario?

From: PJL

Yes, group membership is aggregated from the collection of installer providers. Multiple providers can contribute membership associations to a single group. Or how about this question: can "Bob" be authenticated by the SQL ATN provider, and put into the "Human Resources" group via the LDAP provider? I believe this does work.

More information...

I would encourage you to use these resources to learn more about WebLogic Security:

• Security Fundamentals - official WebLogic security primer
  
  
  
  
  
  



• WebLogic Server SSPI - the CSS security architecture
  
  
  
  
  
  



• SSPI Provider Samples - reading aboout the SSPI is good, but coding is even better. Try building your own ATN provider.
  
  
  
  
  
  



• Foundations of WLP Security - official doc about how WLP integrates into WLS Security
  
  
  
  
  
  



• Implementing SSO with the WLS SSPI - my dev2dev blog on SSO with Identity Asserters
  
  
  
  
  
  



• JAAS Fundamantals - a dev2dev article by Bill Kemp and Rich Helton
  
  
  
  
  
  



• Bastion - a blog devoted to WebLogic Security
  
  
  

Technorati Tags: WebLogic,Security,Authentication,WebLogicPortal,JAAS

Comments from original blog

• 
  
  
  
  

  Carlo -

  
  
  
  
  
  
  
  
  

  OK, good to hear that it worked for you!

  
  
  
  
  
  
  
  
  

  We don't certify any other authorizers/role mappers. It sounds like at least some use cases work.

  
  
  
  
  
  
  
  
  

  Where my comment comes from is the fact that historically we had code that went around the SSPI and directly to embedded LDAP. Based on your feedback, I looked through the current code base and didn't find anything like that. I will check with the engineer who owns that code to verify. So I might have been wrong in saying it will not work at all.

  
  
  
  
  
  
  
  
  

  I did find a couple of places where you may see odd behavior:

  
  
  
  
  
  
  
  
  
  
  
  
  
  
  • There is code to check if the Admin server is running when doing any policy updates. This is because embedded LDAP relies on the Admin server for distribution of updates in the embedded LDAP replicates in a cluster. You will probably see errors in your logs if your Admin server is down, even if you aren't using embedded LDAP.
    
    
    
    
    
  
  
  
  • WLP has a class called LDAPChangeListener which flushes a role policy cache entry if a role policy has been updated in embedded LDAP. If you are running in a cluster, and are not using embedded LDAP, it looks like you will have to redeploy the application to get the updated role policy recognized across the cluster. Can you verify if this is true with your system?
    
    
  
  
  
  
  
  
  
  
  
  
  

  Thanks for the correction!

  
  
  
  
  
  
  
  
  

  Regards - PJL

  
  
  
  
  
  
  
  
  

  Posted by: plaird on January 2, 2008 at 11:31 PM

  
  
  
  
  
  
  

• 
  
  
  
  
  
  
  
  

  Hi Peter thank you for your answer. Why should the protection of WLP assets (e.g. Portlets) not work? I have written my own XACML Authorizer (based on the OpenSource SUN XACML implementation) and a RoleMapper also and it works. If WLP correctly use the WebLogic Security framework, it should work and fortunately it does ;-) Did you mean that in a future version it will not work? This scaries me because we are strongly basing our security on these implementations (and on XACML). ciao carlo

  
  
  
  
  
  
  
  
  

  Posted by: cdrcdr on December 21, 2007 at 6:19 AM

  
  
  
  
  
  
  

• 
  
  
  
  
  
  
  
  

  Carlo -

  
  
  
  
  
  
  
  
  

  What types of resources do you wish to manage with the Role and Access policies? Do you wish to entitle WLP assets such as portlets and content items, or JEE assets? For JEE assets, you could use an external repository by plugging in additional providers into the SSPI.

  
  
  
  
  
  
  
  
  

  But as for WLP assets, first the bad news. You will not be able to replace the entitlement engine that WLP uses for WLP assets. But I would actually argue that you don't want to replace the entitlements engine, you really want to replace the runtime policy repository. Unfortunately, WLP does not currently support storing WLP policies in anything other than embedded LDAP, except in one case (see ALES link below).

  
  
  
  
  
  
  
  
  

  While this isn't great news, WLP will at least remove the embedded LDAP dependency when WLP ships on WLS 10.3. You will be able to store your runtime ploicy repository in a DB then.

  
  
  
  
  
  
  
  
  

  Now for the good news...

  
  
  
  
  
  
  
  
  

  There is a solution available today. I would encourage you to look at ALES, because it does what you want to do. It centralizes role and policy management in an external repository.

  
  
  
  
  
  
  
  
  

  But if ALES is not suitable, there is another potential workaround here. It is possible to *manage* the policies in your external system, and then periodically sync the policies into the *runtime* repository (the embedded LDAP now, DB in a later release). An issue will be figuring out how to author WLP policies; specifically being able to create the WLP asset resource strings. Also, you will need to figure out how to allow for the external management tool to discover the set of manageable resources that do not already have policies.

  
  
  
  
  
  
  
  
  

  Hope this helps... PJL

  
  
  
  
  
  
  
  
  

  Posted by: plaird on December 14, 2007 at 8:34 AM

  
  
  
  
  
  
  

• 
  
  
  
  
  
  
  
  

  Great article! One question: we have our RoleAssignmentPolicies (XACML)as well as the AccessPolicies (XACML)in differnet repositories: we need to wtite our own XACML based authorizer (and Entitlements engine) and (possibly) remove the BEA one from the realm. Would it be possible? There would be problem/limitation doing so? regards carlo

  
  
  
  
  
  
  
  
  

  Posted by: cdrcdr on December 13, 2007 at 5:26 AM

  
  
  
  
  
  
  

• 
  
  
  
  
  
  
  
  

  Josh - I haven't worked with the LDAP providers in years, so I can't comment on the specifics. But in the follow up blog entry to this one, I explain how to dive into the cssWlSecurityProviders.jar to find the implementations of the BEA Atn Providers and how providers often extend other providers.

  
  
  
  
  
  
  
  
  

  By doing that now, I see that the BEA IPlanetAuthenticator extends the base LDAPAutenticator, which already implements UserEditor and GroupEditor. If you wish to implement custom logic for those mbeans, extending the BEA IPlanetAuthenticator provider is probably the way to go. You would create a subclass overriding the UserEditor and GroupEditor methods as necessary, and then wire it up using an XML descriptor.

  
  
  
  
  
  
  
  
  

  Look to the IPlanetAuthenticator itself as an example of how to wire up a provider subclass. Put your custom atn provider in its own JAR in the same directory as cssWlSecurityProviders.jar and you should be good to go.

  
  
  
  
  
  
  
  
  

  PJL

  
  
  
  
  
  
  
  
  

  Posted by: plaird on October 18, 2007 at 9:15 AM

  
  
  
  
  
  
  

• 
  
  
  
  
  
  
  
  

  Hi Peter, What steps would I need to take to add the UserEditor and GroupEditor MBeans to the IPlanetAuthenticator? If I intend for users to be created using a custom objectClass defined in the iPlanet Directory Server that has custom attributes, I'm assuming that I'll have to customize the MBean to do this. Is this correct? Thanks, Josh

  
  
  
  
  
  
  
  
  

  Posted by: joshbrookes on October 17, 2007 at 11:28 AM

  
  
  
  
  
  
  

• 
  
  
  
  
  
  
  
  

  Hi Luciano - yes, this is why we are keen to eliminate internal LDAP as the repository for ATZ. The best way is to have a Propagation inventory that contains a backup of your policies. In that case, you can wipe it clean, and then reapply the inventory (this is not so simple if you do admin work in production, you will need to be careful about the merge). Also, a colleague was looking into a more fine grained fix (directly updating internal LDAP to fix the problem records). I don't know off-hand where he ended up with that - I will point him to this entry. Ciao, PJL

  
  
  
  
  
  
  
  
  

  Posted by: plaird on September 24, 2007 at 11:40 PM

  
  
  
  
  
  
  

• 
  
  
  
  
  
  
  
  

  Hello Peter, very interesting reading. I wish that more articles like this one could be published by Bea. I take advantage of this blog to ask you a question: we have hit on a Portal9.2Mp1 production installation the infamous out of sync between embedded Ldap and the portal db (p13n tables). Result, Delegated Admin page fails with a NPE and Entitlements also are not very well. It's easy to fix this problem in a non prod environment (wipe p13n tables, wipe ldap files) but which is the recommended way to deal with this issue in a clustered production environment? Thanls a lot Luciano Fiandesio

  
  
  
  
  
  
  
  
  

  Posted by: koevet on September 24, 2007 at 11:21 PM

  
  
  
  
  
  
  

Want short SaaS/Cloud news updates throughout your day? Subscribe to the ondemand Twitter microfeed. http://twitter.com/ondemand

Enterprise Greasemonkey: Solving the Greasemonkey Script Versioning Problem

As I have covered in previous blogs, Greasemonkey is a powerful client-side tool for augmenting web sites or creating mashups. It consists of a Firefox plugin coupled with scripts that are written and installed to modify web pages as they return from a web server. When this tool is brought into the enterprise, IT must sort out issues like security and deployment. I covered security in my last post, and in this installment I will look at how IT can solve deployment and versioning issues for Greasemonkey scripts.

NOTE: this blog entry was originally posted August 19th, 2007 on my previous blogging system (dev2dev.bea.com). Comments on the old blog were not transferred.

This is part 5 of a series of blog entries on Greasemonkey mashups.

• Blog 1: More Mashups: Using Greasemonkey to Weave New Features into Web Sites
• Blog 2: Building a Greasemonkey Mashup Tutorial
• Blog 3: Greasemonkey in the Enterprise: When is GM the Right Tool for IT?
• Blog 4: Beware of Greasemonkey's Inverted Security Model
• Blog 5: Solving the Greasemonkey Script Versioning Problem

The Need for Greasemonkey Script Deployment and Versioning

For this blog entry, imagine a web application in the enterprise with these characteristics:

• It is a closed source packaged application, purchased from an external vendor.
• It is used by a modest sized group of users, all of which are comfortable with computers and web browsing
• There are a couple of missing features that dramatically hurt productivity
• Those features can be easily woven into the application using a Greasemonkey script

Now, any one of those affected users could write the Greasemonkey script without involving IT. This script could then be passed around via email or a shared drive amongst colleagues. But there are few problems with this ad hoc approach to Greasemonkey:

• As the script evolves, distribution and version management of the script will be difficult.
• As new users are introduced to the web application, there is no formal process for getting them going with the script.
• GM scripts are like .exe's - they can be host to malicious code. Unmanaged distribution could open the door for a hacker.
• It is IT's mission to be the solution provider - IT should provide the Greasemonkey script.

Clearly, while IT can let the user community fend for themselves on this project, it would be far better for IT to own the solution. However, as always, unless IT can provide a solution quickly the users are apt to go with the ad hoc approach. Hopefully this blog entry will help you rapidly develop a sustainable solution, and add Greasemonkey to the list of official solutions for your enteprise.

Solving the Deployment and Versioning Issues for Greasemonkey Scripts

The rest of this blog entry discusses a solution that can provide manageability around Greasemonkey in the enterprise. It can solve the issues listed above, particularly the issues around deployment and versioning of a Greasemonkey script. This solution is by no means the only way to address these issues, but hopefully you will find it satisfies your requirements. The following describes characteristics of the solution:

• It specifies a new landing page, or Gateway page, for the web application that users will hit before going into the app
• This page can contain whatever you want, but it also has elements to help determine if the GM script is installed and up to date
• The solution enforces the use of the Greasemonkey script (though it could be easily changed to make it only optional)
• It provides version checking
• It does not require any changes to the closed source web application
• It is not foolproof - if the user avoids the Gateway page using a bookmark the enforcement is not run

The graphic below shows how the Gateway page fronts the web application to make sure the user has the proper Greasemonkey install. Ideally, the Gatekeeper page would be integrated into the web application's login page so a user could not bookmark their way around the enforcement. If the browser is not properly configured, the Gateway page obscures the Enter the Site button until the problem is corrected. Also note that the proper version of the Greasemonkey script should be located on a web server defined and managed by IT so the Gatekeeper page can direct the user to it if necessary.

Versioning is implemented by including a div element on the Gateway page with the version number of the script that users should be using.

<div id="gm-script-ver-415" />

The Greasemonkey script looks for the div tag with it's version number. If it does not find it, it will not make the Enter the Site link visible.

 

The Solution Step by Step

Check 1: Is the browser Firefox? If not, a message discloses the problem.

Check 2: Is Greasemonkey and the script installed? If not, the page offers the download links for both.

Check 3: Is the Greasemonkey script the current version? If not, the page offers the download link for the latest version.

Success: The browser is properly configured. The user is allowed to continue if all checks pass.

Implementing the Solution

I didn't include the code in this blog but it is attached here. The code is fairly short, and so you should be able to repurpose it for your needs quickly. Also, for illustration, I have deployed an online demo.

Online Demo

I am hoping others will provide alternative solutions - please speak up if you have built one. The solution I built is passive - it requires the user to navigate across the Gateway page. It is easy to imagine a more active solution, one that would use an XmlHttpRequest to periodically phone home to see if an updated script has been published. That type of solution would need to cache the answer, otherwise it's impact to the network could be substantial. I would think that the GM preference store could be used as a cache.

Greasemonkey Versioning on the Web:

There are others who have talked about the versioning issue. Here are some links:

GMVC (Greasemonkey Version Control)








"The objective of this project is to create a database-driven repository of GreaseMonkey Userscripts which allows for the archiving of previous versions, the release of production versions and the limited released of alpha and beta test versions through the same site."

AllPeers Blog Entry








"A first step would be to give web authors at least the option of making their sites script-friendly. This would involve placing a special header on their webpages that can be tied to a specific version of a Greasemonkey script, like so:




<head> <meta greasemonkey:somescript.js="1.2"/> </head> "

Jeff Barr's Blog








"At some point I could see the need for what we could call "Enterprise Greasemonkey," a tightly packaged version of Greasemonkey with a number of scripts installed and locked in to place. This would give system administrators the ability to deploy specialized versions of Firefox to users who don't need to know how to install, customize, or disable Greasemonkey scripts."

Resources:

• Online Demo
  
  
  
  
  
  



• Code Download
  
  
  
  
  
  



• Greasemonkey Home
  
  
  
  
  
  



• Dive Into Greasemonkey - a great guide to GM
  
  
  

Technorati Tags: Greasemonkey,Enterprise

Want short SaaS/Cloud news updates throughout your day? Subscribe to the ondemand Twitter microfeed. http://twitter.com/ondemand

Enterprise Greasemonkey: Beware of Greasemonkey's Inverted Security Model

I have been blogging about the power and usefulness of a tool called Greasemonkey. I have also explained when Greasemonkey is a good tool for use within the enterprise. But before you rush off and use it in your next IT project, you must understand an important issue with the tool. That issue specifically is Greasemonkey's security model, which was designed to protect benevolent scripts from evil websites. But from IT's point of view, the Greasemonkey security model is inverted - it trusts the wrong people. Within the enterprise, the IT hosted websites are trusted. It is the Greasemonkey scripts that may be evil. This blog entry explains the issue, and discusses some coping strategies.

NOTE: this blog entry was originally posted August 18th, 2007 on my previous blogging system (dev2dev.bea.com). Comments on the old blog were not transferred.

This is part 4 of a series of blog entries on Greasemonkey mashups.

• Blog 1: More Mashups: Using Greasemonkey to Weave New Features into Web Sites
• Blog 2: Building a Greasemonkey Mashup Tutorial
• Blog 3: Greasemonkey in the Enterprise: When is GM the Right Tool for IT?
• Blog 4: Beware of Greasemonkey's Inverted Security Model
• Blog 5: Solving the Greasemonkey Script Versioning Problem

The Power of Greasemonkey

A discussion of the Greasemonkey (GM) security model needs to start first with a discussion of the power of Greasemonkey. Greasemonkey scripts have enormous power, and so a security model is key to its design. In fact, the original version of GM got the model wrong, which led to urgent pleas to uninstall GM until the security model was fixed. The urgency of that issue was due to the danger of misuse of Greasemonkey. And that danger is directly related to GM's power and capabilities.

The first thing to understand about Greasemonkey is that it has full access to the web page. If a web page is displaying sensitive information like account numbers, Greasemonkey can see it. Therefore, a compromised Greasemonkey can do great damage by virtue of the information it can steal.

The second issue to understand is that Greasemonkey is powered by JavaScript and has access to features like event handlers. This can enable GM to snoop on anything the user is doing within the page. For example, a compromised Greasemonkey could capture user input, like the entry of a password.

Finally, Greasemonkey operates at a higher privilege level than normal JavaScript, giving it even more power. The most important capability is the ability for Greasemonkey to be immune to cross domain browser security. Normally, HTTP requests issued from JavaScript (XmlHttpRequest) can only target URLs in the same network domain (e.g. bea.com) as the parent page. This restriction was put in place to help limit (it does not totally prevent) cross site scripting (XSS) attacks. However Greasemonkey, as a plugin, is immune to this restriction. This is a most useful feature when building mashups, but it is does mean that Greasemonkey is operating with higher privileges. It can issue requests to whatever URL it wants, perhaps allowing it to send sensitive data to a malicious web server.

In summary, Greasemonkey is a powerful tool. But just as this power can be put to good use, it can also cause much damage when under the control of malicious parties. The rest of the blog describes how Greasemonkey provides protection, and why IT will have concerns about it in the enterprise.

The Greasemonkey Security Model - Trust the Scripts

Currently, Greasemonkey is a tool in use on the greater world wide web. I don't know the number of people using it, but let's speculate that at most its only a few percent of the users on the web. Let's also speculate that the people using it are fairly sophisticated computer users that know what they are doing. In this situation, we have a small community of users that probably don't attract a lot of attention from the black hats out there. Even if they did, the users have the ability to self-regulate and guard against attackers. Every script is human readable, and so users can look at every script before installing them to determine if the script is safe.

With this understanding of the use case, we can now look at the security model. The Greasemonkey security model operates with the following assumptions:

• Trust the Greasemonkey script; the user installed it and therefore it can be trusted not to abuse the powers described above.
• Do NOT trust the targeted web sites. Do not allow those sites any access to GM objects or APIs.

What this means is that the focus of the Greasemonkey security model is on malicious web sites. This came about because the first security model was vulnerable to such attacks. A well crafted web site could steal cookies and even files off the machine of the unsuspecting Greasemonkey user. The security model was revised in 2005, and great care has been taken to prevent web sites from hijaking the privileges of Greasemonkey to do harm. For a great article on how this was accomplished, read Mark Pilgrim's explanation of XPCNativeWrappers and how they protect GM.

While attacks from malicious web sites should no longer be a problem, Greasemonkey is still vulnerable from certain kinds of attacks. Specifically, the security model does NOT have facilities for detecting or preventing malicious user scripts. Therefore, the user must be careful to only install scripts from trusted sources. This model is in use for the public web, but is it the right model for the enterprise?

The Enterprise Greasemonkey Security Model - an Inversion of Trust

Moving into the Enterprise, the angels and demons flip sides. In the enterprise, IT primarily owns the web sites. Rogue IT employees aside, these sites can be considered trusted and safe. But in this case the GM users aren't as sophisticated, and there is greater potential for them picking up malicious scripts. These are the same users that have been clicking on .EXE email attachments for years. IT cannot trust that this user community will correctly protect themselves from evil scripts.

From IT's point of view, the Greasemonkey security model is inverted - it trusts the wrong people.

Whether this is a fatal flaw that prevents an enterprise from using Greasemonkey universally is a decision IT must own. Personally, I don't think Greasemonkey should be a part of an enterprise wide application roll-out. But I do still think it has it's place in niche solutions. The Greasemonkey Selection Framework introduced in my previous post should help guide when it is the right tool.

Admittedly, it is valid to view any sanctioned Greasemonkey use as reckless, because it could open a Pandora's box. Once users get a hold of it for authorized uses, it may lead to other unauthorized use within the enterprise. This is something for IT to bear in mind when considering if Greasemonkey is an appropriate tool. As a counterpoint, malicious attacks aren't limited to Greasemonkey scripts. .DOC and .PDF files both have been used in the past in attacks, but that has not prevented enterprise use of those technologies.

Malicious Greasemonkey - a Real World Example

To show that Greasemonkey scripts can be a real danger, take a look at this image below. It is a screen shot of the public Greasemonkey script repository, and it currently displays a big warning message. Apparently, a malicious script writer has been publishing evil scripts to the public at large.

One could argue that this proves that the community approach works. Community members discovered the malicious behavior and have taken action to remedy it. But within the enterprise, would the users be able to catch such a problem?

Enterprise Solutions for the Greasemonkey Security Model

Now that you are aware of the problem, let's talk about how IT can solve the problem of the inverted security model. Unfortunately, a server side solution is not attainable. By design, a content page cannot know about or have access to the user script. Therefore a server side solution cannot prevent a malicious script from running on the page. In fact, public web sites that generate their revenue through ads have feared this problem for years. There is no way for these sites to stop the ad blocking Greasemonkey scripts.

We must look to the client for the solution. Unfortunately, Greasemonkey does not currently have a technical solution to this problem. For instance, there isn't a feature that prevents non-IT approved Greasemonkey scripts from being installed. Once the plugin is installed, the user is free to install any script, and there is no way to detect if that script has been tampered with. So if a coworker sends out an email like "Check this out, I updated the script to add a new feature", unwitting users may pick up a malicious script.

Instead, IT must rely on some coping strategies:

• Train workers to treat Greasemonkey scripts with as much suspicion as an .EXE file
• IT must host a read-only web site for all scripts to be published where they cannot be tampered with; do not just throw them on a file system
• Beg the Greasemonkey developers to add a signing feature

Further Reading on the Greasemonkey Security Model

• Mark Pilgrim's explanation of XPCNativeWrappers and how they protect GM. A must read for understanding how it works.
• Original Greasemonkey Fatally Flawed - mail thread discussing the flaw with the original security model.
• Top 10 Firefox Extensions to Avoid - Greasemonkey makes the list because of the security model.
• Evil Scripts in the Public Repository - blog entry talking about how userscripts.org now must carry the warning about the evil scripts.

Final Greasemonkey Blog Post Coming Shortly...

The last post in this Greasemonkey series should be done soon...I will show how I implemented a deployment and versioning system for Greasemonkey scripts.

Technorati Tags: Greasemonkey,Enterprise Security

Want short SaaS/Cloud news updates throughout your day? Subscribe to the ondemand Twitter microfeed. http://twitter.com/ondemand

Greasemonkey in the Enterprise: When is GM the Right Tool for IT?

As I have covered in previous blogs, Greasemonkey is a powerful client-side tool for augmenting web sites or creating mashups. It consists of a Firefox plugin coupled with scripts that are written and installed to modify web pages as they return from a web server. Greasemonkey generally is a tool for techies who want to tweak their favorite sites around the web. But does Greasemonkey have a place in the toolbox of IT departments in the enterprise? My next few blog entries will work towards an answer to that question. In this installment I will introduce a framework for measuring whether Greasemonkey is a good solution for a specific enterprise project.

NOTE: this blog entry was originally posted August 17th, 2007 on my previous blogging system (dev2dev.bea.com). Comments on the old blog were not transferred.

This is part 3 of a series of blog entries on Greasemonkey mashups.

• Blog 1: More Mashups: Using Greasemonkey to Weave New Features into Web Sites
• Blog 2: Building a Greasemonkey Mashup Tutorial
• Blog 3: Greasemonkey in the Enterprise: When is GM the Right Tool for IT?
• Blog 4: Beware of Greasemonkey's Inverted Security Model
• Blog 5: Solving the Greasemonkey Script Versioning Problem

 

An Enterprise Use Case for Greasemonkey

You probably did not learn about Greasemonkey (GM) in a Computer Science class at University. When drawing up an ideal solution for delivering a web application, Greasemonkey is probably no where in sight. The truth is Greasemonkey is a pragmatic solution for real world problems when other options aren't available. It is not the cleanest solution, but it makes up for that by being effective. It will always have detractors who will dismiss it as a hack, and an evil one at that. While its shortcomings cannot be denied, it is a mistake to dismiss it.

Greasemonkey has the potential of fast tracking IT projects that would otherwise never get implemented. It can also lower the bar for IT skill sets - a junior scripter can use it to modify the most complex of web applications. I feel that Greasemonkey deserves a place in your IT toolbox, and should be an option when it is an appropriate solution.

But I will be the first to say that Greasemonkey is not for everyone, and is not for every project. Greasemonkey definately has a sweet spot. Outside of that sweet spot, you are best off looking at another solution like other mashup tools or custom development.

For a quick example of good GM use case, imagine a web application in the enterprise with these characteristics:

• It is a closed source packaged application, purchased and installed from an external vendor by IT.
• It is used by a modest sized group of users, all of which are comfortable with computers and web browsing
• There are a couple of missing features that dramatically hurt productivity
• Those features can be easily woven into the application using a Greasemonkey script

This web application would make a good candidate for augmentation with Greasemonkey. A GM script could be quickly created that would add the missing features without needing to acquire the source code for the application. The deployment of the script would be relatively simple - the user population is modest in size and are technically competent. IT could be a hero by providing a quick solution to an expensive problem.

But what makes this use case a good fit for Greasemonkey? What other applications are good candidates for a Greasemonkey mashup/augmentation? What guidelines should you use when deciding if Greasemonkey is right for a given project? This blog will answer these questions.

Greasemonkey Selection Framework

This section provides a framework for evaluating whether Greasemonkey is a good fit for an enterprise project. Like any software selection process, you must consider many factors before choosing a best fit solution. You cannot base your decision on a single factor; you must sum the overall suitability against the project requirements. The list below enumerates a number of factors to look at before making your choice. For each factor, I explain when Greasemonkey is best suited.

  Factor: Do you have access to the source code of the web application?
Description: IT brings in many packaged applications from external vendors. In such cases, IT may not have access to any source code, or only a partial set (like the HTML files). For applications home grown within IT, this is not an issue as the source code is available.
Greasemonkey Fit: When the source code is available, it may be easier to just update the original application. Greasemonkey is indicated more when the source code is unavailable.

 Factor: The application is home grown and the source code is available. But updating the application is very risky?
Description: Even if the source code for an application is available, it may not be cost effective to update the application directly. Perhaps all of the original developers are gone, and there is little documentation on how the site was built. Or perhaps the current staff is unfamiliar with the technology that was used to implement the site. If the code base is complex, it may be risky to make any modification to the source code.
Greasemonkey Fit: Greasemonkey can be a safer solution for adding new features to web applications that are risky to touch. The Greasemonkey script is externalized from the web application, and so the new development is clearly separated from the legacy application.

 Factor: How critical is the feature to be added?
Description: Is the feature a productivity enhancement, or is the application as-is no longer valid without the update? An example of the latter would be a feature related to a compliance project. In order for the legacy application to update company financial data, a new "explanation" field needs to be added to a web form for auditing purposes. Users must not submit this form without the added field.
Greasemonkey Fit: It would be difficult to enforce that a user have the Greasemonkey installed and up to date (although the last blog entry in this series will offer a possible solution for this). Therefore, if an application is not valid without the new feature, Greasemonkey may not be the right solution for implementing that feature. For optional features such as productivity enhancements, Greasemonkey is a great solution.

 Factor: Is Firefox certified for use in the enterprise, and does it work with the target application?
Description: This factor is obvious, but be careful not to miss this in your software selection. Greasemonkey requires Firefox (there have been attempts to port to IE (gm4ie, GreasemonkIE), but are they complete/solid?). Also, some web applications may not work correctly with Firefox.
Greasemonkey Fit: If your enterprise does not support users on Firefox, Greasemonkey is not an available solution. Also, if the target web application does not work well with Firefox, Greasemonkey is not a great fit for the project.

 Factor: To what degree are the target users computer literate?
Description: Within the enterprise, there is a broad range of computers skills amongst the employees. Greasemonkey does require users to be able to follow directions on installing Firefox, the Greasemonkey plugin and the required scripts.
Greasemonkey Fit: The more computer literate the user base, the better for Greasemonkey. While installing plugins and scripts seems like a no-brainer for anyone that would be reading this blog, it is a true obstacle for many within the enterprise.

 Factor: What size is the user population that needs the new feature?
Description: The appeal of web applications is in their ease of deployment. IT need only manage the application on a few server machines in the data center. Updates are efficiently deployed. Client side solutions are generally more expensive to deploy, as each client needs to be updated with each new version.
Greasemonkey Fit: The cost of deploying a Greasemonkey script to a small user population is likely modest. On the other hand, deploying a new version of a Greasemonkey script to a huge user population is an expensive proposition, particularly when computer literacy is an issue (see above). Greasemonkey is best when the user population is small.

 Factor: Is the application exposed to the public internet?
Description: Many enterprise applications are available to a closed audience of employees and partners. But some applications are also exposed out to customers and the general public on the internet.
Greasemonkey Fit: Because Greasemonkey requires Firefox, the GM plugin, and the proper user scripts installed, Greasemonkey is a good solution when the user base is well known and constrained. Otherwise support costs and customer complaints will be high ("Hello, Avitek Industries, how may I help you?"; "Your website says I need Firefox. What is a Firefox?").

 Factor: How often is the page structure in the web application changing?
Description: Regardless of who is changing the web application (IT, or the ISV if it is a packaged application), every update has the potential of breaking existing Greasemonkey scripts. Minor changes to the content will probably be safe, but bigger changes to the page templates will almost certainly cause problems.
Greasemonkey Fit: Greasemonkey works best if the structure of the pages within the target web application is not changing substantially.

 Factor: Does the application manage or expose sensitive information?
Description: Some enterprise web applications are low security risks. The site that hosts a monthly employee newsletter probably is not much of a concern from a security point of view. A payroll system is quite the opposite; the consequence of a security breach is severe.
Greasemonkey Fit: My next blog entry in this series will discuss the Greasemonkey security model and why it is not a great fit for the enterprise. Based on that analysis, Greasemonkey is not a good choice for adding features to highly sensitive enterprise web applications. Further, some IT Managers may feel GM is too risky to allow at all. More to come in the next post...

 Factor: Does the new feature require many changes to the existing web application?
Description: Javascript can update the DOM of an HTML page quite easily. But for each update on a page, there is code involved. Writing raw HTML (in an .html file, a JSP/ASP file, etc) is far easier than a similar effort in JavaScript code.
Greasemonkey Fit: Greasemonkey is a great fit for features that can be implemented with a few snips to the target HTML. As the number of distinct changes to a page increases, the suitability of Greasemonkey decreases.

 Factor: Does the target web application already have JavaScript code that mutates the page?
Description: The web application may have JavaScript code that modifies the page structure. This may be in support of Ajax capabilities, or just the way the initial page load was implemented. A Greasemonkey script runs before any page defined JavaScript runs. This may or may not be a good thing.
Greasemonkey Fit: Implementing a feature with Greasemonkey may be difficult if the page is already mutating itself with JavaScript.

 Factor: Does the feature require communication with a server in a different network domain than the web application?
Description: Browser based programmatic requests initiated from JavaScript (XmlHttpRequests) are restricted in their reach - they must not cross a network domain (e.g. bea.com). This is browser security, and this is generally good. But if you are adding a mashup feature to the web application, this would normally prevent the feature from being implemented in the browser. However, Greasemonkey scripts are not subject to this limitation, and can issue an XmlHttpRequest to any network domain.
Greasemonkey Fit: Greasemonkey is a good fit when you wish to implement the feature in the browser but need to connect to a different network domain.

Favorable Enterprise Greasemonkey References

To see how others have used Greasemonkey on enterprise projects, or for opinions on how Greasemonkey can add value to the Enterprise, consult these links:

Greasemonkey Improves Productivity - this company uses Greasemonkey to speed up enterprise form entry

Enterprise Greasemonkey is Inevitable - "...sooner rather than later we're going to see GM within the enterprise - if only b/c they have the potential to take some of the load off of beleaguered, shortstaffed IT staffs."

Firefox in the Enterprise Working Group - focuses on a larger issue than just Greasemonkey, but this expert group is looking at some of the issues noted above.

Using Greasemonkey to Enhance Auditing - this script adds time logging capabilities to JIRA.

Anti Enterprise Greasemonkey References

And the opposing view. There are those who think IT should stay well away from Greasemonkey:

Greasemonkey Primes Firefox For Embarrassment - this is an article you have to pay good money to read. Here is an excerpt from the abstract: "But IT managers beware: Greasemonkey will cause you nothing but headaches..."

[Greasemonkey] is Evil - "What's evil is the idea you mention that we'll end up making sophisticated infrastructure like automated script updaters in an attempt to turn a quick-and-dirty hack into a robust solution."

The Story Continues...

My next blog entry will discuss the Greasemonkey security model, and why IT will see it as "inverted" from what you would want.

Technorati Tags: Greasemonkey,Enterprise

Want short SaaS/Cloud news updates throughout your day? Subscribe to the ondemand Twitter microfeed. http://twitter.com/ondemand

Want short SaaS/Cloud news updates throughout your day? Subscribe to the ondemand Twitter microfeed. http://twitter.com/ondemand