Perficient Portal Solutions Blog

Subscribe to RSS feed

Archives

Posts Tagged ‘websphere’

Implementing Form Based TAI for the Developer

As identified in another post Full login filter testing for local developer environments, the requirement may arise that developer environments need to fully test implicitLoginFilter without deploying code to another environment.  This post walks thru the code and setup of a form based TAI.

Create a new class which implements TrustAssociationInterceptor. In this class we will pull 3 properties from the WAS configurations of the interceptor. These three properties and a description of the information each will hold are:

  • formid – name of a hidden field in the form utilized for login
  • formidvalue – value of the hidden field that will need to match the value passed thru the request
  • useridfield – name of the form field containing the ID of the user to be logged in

In my implementation I have set these values to the following values:

  • formid = TAI_Form
  • formidvalue = SecretKeyValue
  • useridfield = userid

Once you have everything configured in WAS you will need to create a login form.  I have used

Login.html

<form id=”loginForm” action=”http://localhost:10039/wps/myportal” method=”post”>
User ID: <input type=”text” name=”userid” value=”wpsadmin” /><br/>
<input type=”hidden” name=”TAI_Form” value=”SecretKeyValue” />
<input type=”submit” value=”Submit” />
</form>

CODE:

/**
 * @author Charles Mahoney, Perficient Inc
 */
public class FormBasedTAI implements TrustAssociationInterceptor {

	private static String formID = null;
	private static String formID_Value = null;
	private static String userIDfield = null;
	private static Logger logger = Logger.getLogger(FormBasedTAI.class.getName());

	@Override
	public void cleanup() {	}

	@Override
	public String getType() {return String.format("%s version %s", this.getClass().getName(), this.getVersion());}

	@Override
	public String getVersion() {return "1.0";}

	@Override
	public int initialize(Properties props) throws WebTrustAssociationFailedException {
		logger.entering(this.getClass().getName(), "FormBasedTAI.initialize()");

		// read properties from configuration in WAS
		this.formID = props.getProperty("formid");
		this.formID_Value = props.getProperty("formidvalue");
		this.userIDfield = props.getProperty("useridfield");

		if(!hasAllConfigurations()){
			logger.severe("the required configurations for the FormBasedTAI were not properly set");
			return 1;
		}

		logger.exiting(this.getClass().getName(), "FormBasedTAI.initialize()");
		return 0;
	}

	private boolean hasAllConfigurations(){
		if(StringUtils.isNotBlank(this.formID) 
				&& StringUtils.isNotBlank(this.formID_Value)
				&& StringUtils.isNotBlank(this.userIDfield)
			)
			return true;
		return false;
	}

	@Override
	public boolean isTargetInterceptor(HttpServletRequest req) throws WebTrustAssociationException {
			if(req.getParameter(formID).equalsIgnoreCase(formID_Value)){
				logger.info("Form ID matches desired value");
				return true;
			}else{
				logger.info("The FormID of " + req.getParameter(formID) + " does not match the desired value of " + this.formID_Value);
			}
		return false;
	}

	@Override
	public TAIResult negotiateValidateandEstablishTrust(HttpServletRequest req, HttpServletResponse res) throws WebTrustAssociationFailedException {
		logger.entering(this.getClass().getName(), "FormBasedTAI.negotiate...()");
		if(StringUtils.isNotBlank(req.getParameter(this.userIDfield))){
			return TAIResult.create(HttpServletResponse.SC_OK, req.getParameter(this.userIDfield));
		}
		return TAIResult.create(HttpServletResponse.SC_UNAUTHORIZED);
	}
}

Implementing Cookie Based TAI for the Developer

As identified in another post Full login filter testing for local developer environments, the requirement may arise that developer environments need to fully test implicitLoginFilter without deploying code to another environment.  This post walks thru the code and setup of a form based TAI.

Create a new class which implements TrustAssociationInterceptor. In this class we will pull 1 property from the WAS configurations of the interceptor. The name of this property is “cookieName” and will contain the name of the cookie whose value will be the ID for the user to be logged in.  In my implementation I have set this property equal to “TAIUserID”.

To set the cookie for this TAI I have used the Web Developer Plugin for Firefox, however you may also use the html code below.  Make sure that the domain specified for the cookie matches the domain which portal is accessed.

createTAICookie.html

<script type=”text/javascript”>
function setCookie(c_name,value,exdays)
{
var exdate=new Date();
exdate.setDate(exdate.getDate() + exdays);
var c_value=escape(value) + ((exdays==null) ? “” : “; expires=”+exdate.toUTCString());
document.cookie=c_name + “=” + c_value;
}

setCookie(‘TAIUserID’,’wpsadmin’,1);
window.location = “http://localhost:10039/wps/myportal”;
</script>

CODE:

/**
 * @author Charles Mahoney, Perficient Inc.
 */
public class CookieBasedTAI implements TrustAssociationInterceptor {
	private static String cookie = null;
	private static Logger logger = Logger.getLogger(CookieBasedTAI.class.getName());

	@Override
	public void cleanup() {	}

	@Override
	public String getType() {return String.format("%s version %s", this.getClass().getName(), this.getVersion());}

	@Override
	public String getVersion() {return "1.0";}

	@Override
	public int initialize(Properties props) throws WebTrustAssociationFailedException {
		logger.entering(this.getClass().getName(), "CookieBasedTAI.initialize()");

		// read properties from configuration in WAS
		this.cookie = props.getProperty("cookieName");

		logger.exiting(this.getClass().getName(), "CookieBasedTAI.initialize()");

		if(StringUtils.isBlank(this.cookie)){
			return 1;
		}
		return 0;
	}

	@Override
	public boolean isTargetInterceptor(HttpServletRequest req) throws WebTrustAssociationException {
		logger.info("CookieBasedTAI.isTargetInterceptor()");
		for (Cookie c : req.getCookies()) {
			if (c.getName().equals(this.cookie)){
				logger.info(this.cookie + " cookie exists");
				return true;
			}
		}
		logger.info(this.cookie + " cookie does not exist");
		return false;
	}

	@Override
	public TAIResult negotiateValidateandEstablishTrust(HttpServletRequest req, HttpServletResponse res) throws WebTrustAssociationFailedException {
		logger.entering(this.getClass().getName(), "CookieBasedTAI.negotiate...()");
		for (Cookie c : req.getCookies()) {
			if (c.getName().equals(this.cookie) && StringUtils.isNotBlank(c.getValue())) {
				return TAIResult.create(HttpServletResponse.SC_OK, c.getValue());
			}
		}

		logger.info("Not Authenticated");
		return TAIResult.create(HttpServletResponse.SC_UNAUTHORIZED);
	}
}

Full login filter testing for local developer environments

A majority of enterprise portal implementations utilize some kind of external authentication mechanism. To meet the ever demanding requirements in these same environment the need rises to execute custom code during login process.  Starting in WebSphere Portal 6.1 opened up this capability with the Implicit and Explicit loginfilters. (http://www.ibm.com/developerworks/websphere/library/techarticles/0905_buchwald/0905_buchwald.html)

Many environments do not require different code in the implicit vs explicit login filters or only one filter is utilized; however this is not always the situation.  Below are two examples where there is a need for both filters and possibly the execution of different code depending on the method of authenticating for portal.

  • Network SSO via an implementation of SPNEGO.  In most browsers users will be authenticated to Portal and will execute the implicit login filter.  In the event that a user accesses the portal with a Safari browser the users can login with the login portlet service and execute the explicit login filter.  In the situation the code in both filters may be the same. 
  • Internal and Externally accessible environment with only the external traffic authenticating against an external mechanism such as WebSeal.  All internal traffic, in this example, can have the requirement to execute different code for internal traffic vs external traffic. 

To properly test the implicit login filter the Developer’s local environment will need to have a local Trusted Association Interceptor (TAI) configured in order to recreate the production environments.  In breaking down the way in which users access a TAI enabled Portal environment there are 2 primary flows.  These flows both start with an unauthenticated user requesting a secured resource.

  1. User is redirected to a login page and returns with ample information in the request to pass TAI validation Form Based TAI
  2. User’s initial request contains the necessary information to pass TAI validation.  Possible examples of this would be if the user is coming from WebSEAL, or the user’s browser may already contain the proper security tokens from a SSO implementation (i.e. Ping) Cookie Based TAI

IBM WebSphere Portal Self Registration Portlet Available

In previous versions of IBM WebSphere Portal, one missing feature had been the ability for a new user to self register. It was one of the standard checklist items in a Request For Proposal (RFP) – does your system allow for self registration? We spent countless hours building this capability for many, many clients.

IBM has implemented a set of portlets for self registration and has made them available on their App Store, the IBM Solutions Catalog. You can download the portlets at this page in the catalog.

These portlets were built using IBM’s Web Experience Factory tool. Here is a list of the key features:

  • Self Registration – The registration, or self registration, portlet lets portal users create user IDs to log in to your site and access personalized, or profiled, content. The registration portlet also lets users specify answers to security questions so that they can reset passwords and validate their identities. Users typically access the registration portlet from links that display on your portal site
  • Account Activation – The account activation portlet lets users specify passwords and complete the registration process. Users access the account activation portlet from a URL that the registration portlet sends in an activation e-mail. After users specify passwords in the account activation portlet, they can log in to your site as registered users.
  • Lost Registration email – The lost registration e-mail portlet re-sends account activation e-mails to users. You must deploy the lost registration e-mail portlet on an appropriate portal page for users to access.
  • Forgotten Password – The forgotten password portlet lets users reset their passwords. The forgotten password portlet prompts users to answer security questions. If users provide the correct answers, they can then specify a new password for their account. Users access the forgotten password portlet from a link on the log in page.
  • Profile Update – The profile update portlet lets users modify their profile information after they complete the registration process. Users access the profile update portlet after they complete the registration process and log in to your portal site.

Overall these are nice features to have in your portal. Since the features have been implemented as separate portlets, you can decide which features to turn on for your sites. If you want to offer the forgotten password and profile update feature, but not self registration you can do that.

Installing WebSphere Portal 8 Part 2

Well, if you a regular reader of our blog, you’ll know that I started my WebSphere Portal installation (see Installing WebSphere Portal 8) but forgot to check the system requirements.  So I stopped when Installation Manager told be that Windows Server 2003 was not supported.  Well I got a couple of comments that basically said, come on you baby, just go ahead and install it on Windows Server 2003 Server, it’ll probably work.

So I restarted the install. Never mind that I didn’t have enough memory (RAM, not mine).  I accepted the defaults and entered an ID and password for my portal/websphere administrator.  The fixpacks started to download and as I mentioned before, our network seemed slow, so I closed out my remote connection and decided to check back at a later time to see if the install worked.

Ok, the install finished.  Installation manager wanted to know if I wanted to install a profile or run portal. Since I had not read the documentation too thoroughly, I assumed that a WebSphere profile was created, so I chose to just start Portal.  It seemed that Portal was already started, so I simply opened the browser and navigated to  the correct portal page:  http://____:10039/wps/portal.  In the screen shot you can see the initial portal screen loaded.

I checked the logs and didn’t see any major issues there.  Overall, the installation went very smoothly.  Except for the initial worries about disk space, operating system and memory requirements, I went through the rest of the process without a hitch.

So I’m going to start playing with Portal 8 and see how it goes.

 

Using Splunk for WebSphere Application Server

Splunk hosted a webinar earlier today on their Splunk for WebSphere Application Server 2.0 application. This is an application they wrote that extends Splunk’s already powerful capabilities to provide WebSphere-specific searches and reports.

If you’re not familiar with Splunk, you should take a look. In a nutshell,

Your IT infrastructure generates massive amounts of data. Machine data – generated by websites, applications, servers, networks, mobile devices and the like.

By monitoring and analyzing everything from customer clickstreams and transactions to network activity to call records, Splunk turns your machine data into valuable insights.

Troubleshoot problems and investigate security incidents in minutes (not hours, or days). Monitor your end-to-end infrastructure to avoid service degradation or outages. And gain real-time visibility into customer experience, transactions and behavior. Read the rest of this post »

Maven and WebSphere Web Applications (Part 1)

Web Applications are WAR files that include java code and JSP files with a web.xml deployment descriptor that are intended to implement dynamic web functionality (as opposed to static web functionality which uses HTML files).

A portal team typically uses this packaging technique for the following artifacts:

  • Portal themes and skins
  • web services
  • iWidgets

WebSphere Approach for Web Applications

The WebSphere Application server only understands EAR files. EAR files are collections of WAR and JAR files with an application.xml deployment descriptor. Developers that come from a Tomcat or JBoss (or similar J2EE application server) background may be accustomed to performing a hot deploy that simply involves them placing a WAR or EAR file in a specific directory. The WebSphere deployment is more involved because of clustering and vendor extensions that provide more robust enterprise features.

Now let’s assume you are creating a Spring web service implementation for your business logic. RAD automatically creates an associated EAR project for your WAR project when you choose dynamic web application during the project creation wizard. The EAR file is deployed on the WebSphere_Portal server instance of the WebSphere Application Server that includes your portal application.

The EAR file can be placed on the server using several techniques:

  • administrative console (via the GUI)
  • wsadmin
  • RAD menus that add project to a local server configuration (technique used by many developers during coding/debugging)

The wsadmin approach is the obvious choice for scripting releases. The administrative console approach is a multiple screen wizard that forces developers to choose values for many vendor extensions and security configurations that are typically beyond the domain knowledge of a component developer.

Maven Approach for Web Applications

A best practice of maven is to follow the one artifact for each pom.xml convention. We have already seen that WebSphere expects an EAR file that contains a WAR file for a typical web application. The solution for this problem is to create a multiple module maven project that serves as the parent for the WAR and EAR files that are required.

The deployment of the EAR file is handled by the was6 maven plugin from codehaus. This plugin will require that your Continuous Integration (CI) server handling the deployments has a WebSphere Application Server installation on the same machine. This is required because the was6 plugin is a wrapper for the wsadmin client (which includes an IBM component that handles the secured communications with a remote WAS instance). The configuration of the was6 maven plugin always requires specifying a -DwasHome property value that points to the root of the WAS server installation. I am not aware of any set of JAR files that implement this functionality (unlike the xmlaccess tool discussed in my WebSphere Portal and Maven post that can be implemented by including jars as dependencies of your custom plugin).

Next up I will discuss the file structure of the project used for my proposed solution for web applications.

Next up: Maven and WebSphere Web Applications (Part 2)

The Portal URI Resolution Service

WebSphere Portal 6.0.1 introduced a capability called the URI resolution service or POC servlet  or the Resolver Framework depending on where you see it mentioned. The DeveloperWorks article called Accessing portal content with custom URLs is the most recent and informative post I have found describing this service.

This service was created to allow non-portal sites in your organization to link to your portal content (the acronym POC means Piece of Content). The service works by using the scheme portion of the URI to divert the request to a collection of handlers that use the chain of responsibility pattern to modify a Resolved object which ultimately communicates parameters to portal objects.

Some examples of where this concept is used include:

  • The JSR 286 Web Content Viewer uses POC URIs (prefixed with wcm:). The WCM web content pages work by selecting which page best fits the current content request.
  • The PageBuilder2 themes use this to implement dynamic content spots and many other items.
  • The Lotus Connections Portlets for WebSphere Portal also use POC URIs.
  • The iWidget/Mashup API concepts use this mechanism. In fact, all portlets in WPS 7.0 are wrapped with an iWidget interface via the PageBuilder2 theme.
  • The WebDAV mechanism uses POC URIs for resolving resource requests.

This service can also be used for a few use cases you may not expect:

  • You can create a dynamic web content pages implementation that improves on web content pages (which still require you to create individual portal pages that are configured to certain Site Areas or content folders).
  • You can implement an inter-portlet communication process to replace wires (which require you to create a wire definition through portal administration).

I am going to explore these concepts in more detail in future posts.

Finding Practical Code Samples

You can find examples of resolvers by searching for the plugin.xml files that register them. This unix example would give you a list of EAR files in your installedApps directory:

Read the rest of this post »

The Power of WebSphere Portal Personalization

Personalization (PZN) in WebSphere Portal is one of its most powerful yet overlooked capabilities.  I am surprised how often it is not even considered for everyday scenarios and instead complex custom code is written .  Personalization is often for viewed as simply selecting content from Web Content Management (WCM) based on site areas and matching the content categories with LDAP attributes for a logged in user.  While this is useful, PZN can be used for so much more. PZN rules can be written against any java accessible object (known as an Application Object) making it quite straight forward to write rules against information returned from a web service, database, or any connected system for that matter.

Read the rest of this post »

IBM Sets Record for Middleware Performance

This may be a portal blog but in at least 4/5 of our projects, we hit a services layer.  We need that data and those transactions to meet user requirements.  So I’m always interested in what’s happening in the middleware fields.  Anyway, eWeek has an article about IBM flexing their middleware muscle while setting new performance records.

In an interview with eWEEK, Dave Klavon, director of development for IBM’s WebSphere, said IBM set new records for speed of operation in Java-based software on a Power 780 server and on Power 730 Express as validated by independent SPECJ testing group. SPECjEnterprise 2010 is an industry-standard online transaction processing benchmark that is commonly used to compare the performance of middleware software for online transaction processing applications.

Klavon said these records demonstrate how businesses using  IBM WebSphere middleware on Power7 hardware can get the lowest cost for performance in the industry—one-third that of the nearest competitor. Performance is an important factor for businesses. It speeds applications, reduces the amount of hardware and results in significant savings in hardware, software and energy costs.