Implementing Single Sign On (SSO) with a WebLogic Identity Asserter

I worked on an interop project this week that required me to do something I haven't done in a while - develop an SSO solution for WebLogic Server or WebLogic Portal. In this case, my WebLogic Portal 9.2 instance needed to consume a token in the request header and derive Identity from that. In the WebLogic world, an Identity Asserter is the tool for the job. This blog entry details the steps to implement a custom Identity Asserter with WebLogic Server (or WebLogic Portal).

NOTE: this blog entry was originally posted February 1st, 2007 on my previous blogging system (dev2dev.bea.com).

 

Identity Asserters and Single Sign On

An Identity Asserter is a pluggable WebLogic component that can determine the identity of a user through inspection of a token in a request header, a cookie, or other mechanisms. This is a useful feature to employ when implementing Single Sign On for your WebLogic project. It allows for an external entity to authenticate a user, and enables WebLogic to honor that authentication.

Identity Asserters aren't new. They have been with WebLogic for years. Out of the box, WebLogic provides an Identity Asserter that supports a variety of token types: X509 certificates, SPNEGO tokens, SAML assertion tokens, and CORBA Common Secure Interoperability version 2 (CSIv2). In addition, 3rd party Identity Management vendors will typically have a pre-built WebLogic Identity Asserter available for you.

However, there are times when a custom Identity Asserter is required. This is the approach I pursued on my project. In my case, an external proxy server has authentication capabilities, and places a token on the request to WLP that identifies the user. I needed a custom Identity Asserter that could look for that token, and decode it. To build my custom Identity Asserter, I took the sample from dev2dev and modified it to suit my needs. I have deployed this on WebLogic Portal 9.2 (which is built on WebLogic Server 9.2). The rest of this blog explains the development and configuration steps.

 

Development and Configuration of a Custom Identity Asserter

Below is the list of steps to build and configure the Identity Asserter:

0. Download the sample Identity Asserter from dev2dev

• Available on dev2dev Codeshare here (as of 2009, no longer available. see comments)
• Look for a project called "Sample Security Providers"
• The samples may not be for your exact version of Weblogic, but they will likely be compatible from 8.1 onwards.
• The download will contain a build system as well as samples of other types of providers

1. Unpack and alter the SimpleSampleIdentityAsserter code and descriptor

• Look in src\providers\identityassertion\simple, you will need to modify both .java and .xml files
• Search and replace "SamplePerimeterAtnToken" in all files with the name of your custom token/request header
• In SimpleSampleIdentityAsserterProviderImpl.java make these changes:
  Where the sample code is working with TOKEN_PREFIX in the assertIdentity method, you will need to change the code to parse the value of the token, perhaps decrypting it, and derive the username. The work done here is very specific to the type of token you are expecting.
• If you don't want the container to automatically decode the token payload using Base64 decoding, make sure you have this in the .xml descriptor:

   <MBeanAttribute
    Name          = "Base64DecodingRequired"
    Type          = "boolean"
    Writeable     = "false"
    Default       = "false"
   />

  
  
  
  
  
  
  

2. Go to your WLS/WLP domain home/bin, and execute setDomainEnv.cmd/sh in your command line shell.

3. Navigate back to the root dir of the SSPI sample directory where build.xml exists.

4. Compile with default Ant task ("ant"). The build puts the jar in BEA_HOME/weblogic92/lib/mbeantypes/wlSecurityProviders.jar

5. Edit web.xml of the webapp that will participate in the Identity Assertion and add/update the login-config element:

  <login-config>




    <auth-method>CLIENT-CERT</auth-method>








    <realm-name>Legacy_ThisElementIsIgnored</realm-name>








  </login-config>

6. Launch WLS/WLP (startWebLogic.cmd/sh).

7. Launch the WLS console (usually http://localhost:7001/console), and create a new instance of this Identity Asserter.

• Navigate to Security Realms -> My Realm -> Providers tab -> Authentication sub tab
  
  
  
  
  



• Click "Lock & Edit"
  
  
  
  
  



• Click "New"
  
  
  
  
  



• Name = [give it a meaningful name] Type = SimpleSampleIdentityAsserter
  
  
  
  
  



• Click "Release Configuration"
  
  

8. Restart the server.

9. Target any resource in the web application with a browser in a way that properly populates the token. You should see output from the debug in the Identity Asserter indicating that the user has been identified. If the username exists in a configured authentication provider, the request will be authenticated.

Next Steps: Left as an exercise to the reader:

Rename SimpleSampleIdentityAsserter to something more appropriate

• Change SimpleSampleIdentityAsserter references in .java and .xml files
  
  
  
  
  



• Update the build to reflect the name change
  
  

Additional Resources

SSO Related:

• Official documentation for Identity Asserters for 9.2
  
  
  
  
  
  



• dev2dev Codeshare example (as of 2009, no longer available)
  
  
  
  
  



• SAML Configuration: a good article by Vikrant Sawant on how to configure SAML
  
  
  

Technorati Tags: weblogic,security,sso,identityasserter

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

WebLogic Portal Propagation Tool Field Guide

The WebLogic Portal product offers rich capabilities for propagating Portal applications from one environment to another, often from Staging to Production. Because Portals may be changing in both environments at the same time, a reconciliation step is required to update the target environment. The WebLogic Portal Propagation Tool offers this capability. This blog introduces the Propagation Tool Field Guide, which is now available to discuss best practices and known limitations with the tool.

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

What is the Propagation Tool?

The Propagation Tool's primary purpose in life is to provision WebLogic Portal environments with configuration data. The provisioning can be done for a new WLP environment, or as a promotion of updates on top of an existing environment. A propagation is typically immediately preceded by the promotion of a new EAR file, which contains updates to the code artifacts of the application.

To support this primary mission, the Propagation Tool in WLP 9.2 supports these features:

• Exports database and LDAP configuration artifacts as XML files, all packaged into a single zip file (called an inventory file)
• Advanced reconciliation UI allows an operator to visually choose exactly how to reconcile the two environments
• Promotes the new configuration using the inventory file that came from the visual tool
• All operations can also be done using Ant tasks, as an alternative to the visual tool

For more information on the many features of the Propagation Tool in 9.2, please visit the official documentation. The docs take you through the primary use case of the Propagation Tool - moving WLP applications from one environment to another.

Click here for a more detailed diagram.

Release 9.2 is a Major Milestone

The Propagation Tool in WebLogic Portal 9.2 received major updates from the version offered with WebLogic Portal 8.1 SP5. Most significant were these improvements:

• Eclipse User Interface - provides a visual, tree based view reconciling the configuration artifacts of your Portal environments
• Ant tasks - a rich set of Ant tasks have been provided
• Offline story - the Eclipse UI and Ant tasks combine to provide the ability to do most of the propagation work offline from the running servers
• Content Propagation - ability to move Content Repository artifacts, specifically Content Nodes and Types

Introducing the Field Guide

In support of the major launch, I have been working with customers that are implementing the Propagation Tool in their WLP 9.2 projects. From this experience, I have been assembling a Field Guide that provides:

• Best Practices - how best to employ the new toolsets and be successful with Propagation
• Known Issues - a list of known issues and common pitfalls that have arisen with customers using the tools

This Field Guide is being updated on a regular basis (about once a week at this point) as new customers and new issues arise. You may find the guide linked from this site:

Click here to view the Propagation Tool Field Guide

Encouraging Feedback

Good or bad, we actively seek out feedback from the use of the Propagation Tool. There are multiple channels to do this:

• Support Cases - open a Support case at the eSupport site (see a stack trace, open a case!!!)
• Portal Newsgroup - ask a question on the WLP dev2dev newsgroup
• Professional Services - we are in close contact with the BEA Professional Services team
• Blog about it - like this customer did, Anders Mathisen

We like to hear about positive experiences, and when that isn't possible, constructive criticism and questions about problems with the tool.

Resources

• Official Documentation - BEA edocs
• Propagation Tool Field Guide - linked from wlp.bea.com
• My Blog - I will blog about Propagation from time to time, like this entry that demonstrates non-standard uses of the Propagation Tool.

Technorati Tags: weblogicportal

Off the Beaten Path with WebLogic Portal's Propagation Tool

Fast becoming the Swiss army knife of WebLogic Portal 9.2, I will discuss some non-standard uses for the WebLogic Portal Propagation Tool. In addition to a myriad of application provisioning use cases, the Propagation Tool can provide solutions to problems in areas such as Change Reporting as well as Backup and Recovery of WebLogic Portal applications.

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

What is the Propagation Tool?

The Propagation Tool's primary purpose in life is to provision WebLogic Portal environments with configuration data. The provisioning can be done for a new WLP environment, or as a promotion of updates on top of an existing environment. A propagation is typically immediately preceded by the promotion of a new EAR file, which contains updates to the code artifacts of the application.

To support this primary mission, the Propagation Tool in WLP 9.2 supports these features:

• Exports database and LDAP configuration artifacts as XML files, all packaged into a single zip file (called an inventory file)
• Advanced reconciliation UI allows an operator to visually choose exactly how to reconcile the two environments
• Promotes the new configuration using the inventory file that came from the visual tool
• All operations can also be done using Ant tasks, as an alternative to the visual tool

For more information on the many features of the Propagation Tool in 9.2, please visit the official documentation. The docs take you through the primary use case of the Propagation Tool - moving WLP applications from one environment to another.

This blog entry covers some alternate use cases for the Propagation Tool. The toolset that we built is very flexible and can cover more than just promotion use cases. I will cover 2 use cases in this blog that uses the Propagation Tool on a single environment. Before I cover the use cases, I will talk about a best practice that is relevant to this discussion.

 

Best Practice: Historical Inventories

These use cases require that you create and retain a series of historical inventories for the environment. This is a good idea for so many reasons that we recommend that inventories be retained in source code control (if size allows) or a backed up disk drive (for huge inventories). The idea is to periodically take a snapshot of the environment and store that inventory. Think of your inventory as a peer to your code assets - the same care you put into maintaining historical versions of your code should be applied to inventories.

Note: inventory snapshots do not replace the need to do database and file system backups.

 

Use Case 1: Change Reporting

Do you ever wonder how much configuration work has been done in an environment over a period of time? The Propagation Tool can help answer that question. It provides a logical view of exactly what has changed in an environment, as an alternative to dredging through audit logs.

For example, imagine that you have taken a baseline inventory on December 1st. On December 15th, you want to see what Admin changes have been made to your WLP enviroment. To do this, export a new inventory and compare it the baseline inventory with the Propagation Tool Eclipse User Interface. The user interface will show you the net differences in a logical, visual format.

 

Use Case 2: Backup and Recovery

The pain of all operations people is to have to recover an application to a previous state. While traditional backup and recovery procedures are still relevant for WLP environments, the Propagation Tool can provide additional options that will help you get home in time for dinner. Database backups and file system backups can provide point in time recovery options, but may be too big a hammer for certain cases. The Propagation Tool is a more precise instrument, but it does not handle all configuration data , so it does have limits in a recovery role. I will show some cases where the Propagation Tool is the right tool for the job.

For example, imagine that your Portal Administrator deletes a page on a desktop in production accidentally, and the problem is not discovered for 3 hours. After flogging him with a bundle of network cables, what is your next step? A point-in-time database restore is probably not an appealing option, as it will take a lot of your time, will require application downtime, and will result in data loss of updates made after the mistake. Instead, consider a targeted propagation that fixes the problem at the logical level. Using a historical inventory, the Propagation Tool can be used to restore that specific desktop in the production environment. This can be done while users are interacting with the application, so it is a quick and easy approach. It is also precise - it will not disturb any configuration artifacts outside of the scope of the propagation.

Here is a table that suggests a toolset to use for different failure scenarios. In cases where only WLP artifacts in the application need to be restored, the Propagation Tool is generally the best option. The table shows a sample set of use cases, but in fact the Propagation Tool can handle many more types of data in a similar fashion. Also, it should be noted that any problem that is fixable using the Propagation Tool is also fixable by manually affecting changes through the Portal Admin Tool.

* For Portal Framework use cases, be aware that the Propagation Tool cannot restore end user customizations if the artifact was deleted, if any exist for that asset. For example, if a user made customizations to the deleted page, the Propagation Tool cannot restore that. If user customizations are important to recover, another tool called XIP could be used together with Propagation.

Additional Resources

• Propagation official documentation
• Propagation Tool Field Guide - best practices, known issues
• developer.com article - a look at the 8.1 SP5 web app based Propagation Tool (an ancestor to the 9.2 tool)

Technorati Tags: weblogicportal,weblogic

Build Enterprise Mashups with BEA WebLogic Portal 9.2

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

Plug: Don't miss my Webinar on Wednesday, January 10th, 2007 that demonstrates how BEA WebLogic Portal can power Enterprise Mashups today!

Mashups Gain Momentum in the Enterprise

Enterprises are beginning to look at a concept called Mashups to facilitate application development within IT. This approach is gaining traction due to these benefits:

• Mashups focus on lightweight integrations of applications which enables rapid development
• An application component is developed once, and is easily reused and integrated elsewhere
• Public availability of massive amounts of Mashup components, such as Google Gadgets, enables IT to build applications at a lower cost

All of these reasons make Mashups a popular choice both in the consumer space, as well as in the enterprise. In this blog, I will discuss how BEA is helping IT deliver on these initiatives.

The Novelty of Consumer Mashups

Need a beer in New York City? There's a mashup for that: NYC Beer Mashup
Want to stalk a celebrity? Here's a mashup that'll help: Celebrity Home Mashup

Amusing? Yes. Useful? Not so much.

The consumer web brought us Mashups, but I expect that more value from this approach will come from the enterprise. BEA has taken the lead on delivering products that will enable enterprises to create dynamic, user-focused, Mashup sites. Let me explain...

Back to basics - what is a Mashup?

You can define a Mashup web application in a variety of ways. Wikipedia starts with a broad definition:

"A mashup is a website or application that combines content from more than one source into an integrated experience."

You can tighten that definition as you like, but I think we need to recognize that this concept eludes a strict definition. I will suggest instead some common attributes that in my opinion are indicative of a Mashup web application:

• The components come from applications that were developed and deployed independently without knowledge of each other



• The components may be implemented using different technology stacks: Java, .NET, RoR, etc.



• It is straight forward to snap the components together, without a heavy weight back end integration. Browser side integrations are acceptable.



• The combined result provides a new useful way of using the components



• Ideally, the user has some capability to define and customize the integrated application

On the consumer web, Google Personalized Home Page is a good representative of these characteristics. For example, you may build your personalized page with Google Map, Travelocity, Currency Converter, and weather gadgets to compose a travel planning mashup.

Building a Mashup

When assembling a Mashup, there are two types of software involved:

• Mashup Composition: composes components into an integrated application. Portal frameworks and browsers often fulfill this role.



• Component Producer: delivers the application component that surfaces on the Mashup.

When looking at WebLogic Portal 9.2, we will identify how it provides capabilities in both of these areas.

WebLogic Portal 9.2 Delivers Enterprise Mashups

An Enterprise Mashup is simply a mashup web application that is deployed to support an Enterprise, targeting it's customers, employees, or partners. WebLogic Portal 9.2 released in June 2006, and offers capabilities to support both Mashup Composition and Component Producer use cases for the enterprise.

To support Mashup Composition, WLP's portal framework serves as the aggregation framework that assembles the components into a unified application. WLP provides two features that enables this capability: URL portlets and WSRP portlets. URL portlets allow any arbitrary URL to be rendered in the Portal. WSRP is a standard that uses Web Services to accomplish the aggregation.

For the Component Production use case, WLP 9.2 introduced a technology called Adrenaline. Ths core capability offered by Adrenaline is unique to WLP amongst our competitors: HTTP addressable portlets. Any portlet can be exposed as a URL, which therefore enables WLP portlets to surface on external web applications using iframes or html streaming approaches.

The beauty of Adrenaline is that it works on top of the existing WLP enterprise portal framework. While competitors seem to view the Enterprise Portal and Enterprise Mashup spaces as separate, BEA WebLogic Portal allows IT to solve the Enterprise Portal and Enterprise Mashup use cases in a single effort with a unified product stack.

More Information

I will be covering this topic in far more detail in my webinar. Be sure to tune in to my Enterprise Mashup webinar on Wednesday, January 10th, 2007. A replay will be available if you miss the show.

For a visual look at why Enterprise Mashups are compelling, take a look at the demo movie that we have created for WebLogic Portal 9.2.

For technical information, review this Adrenaline Article.

Read more about the concepts behind Enterprise Mashups - I like Dion Hinchcliffe's discussion in this blog entry.

 

Technorati Tags: mashup,weblogic,weblogicportal,enterprise2.0