Simplest SSO implementation

OA needs to be done with the project and the Portal of the SSO, two applications were on different servers, but top-level domain name is identical to the simple formula, and I said, it used domain cookie bar, they still will not talk for a long time doing,囧~~~~,

Suppose portal's domain name is portal.xxxx.com in the Portal log is complete, set a cookie:
<% @ Page language = "java" pageEncoding = "UTF-8"%>
<% @ Page import = "javax.servlet .*"%>
"%
/ / Login successful Domain Cookie Settings
Cookie cookie = new Cookie ( "ssoUserId", "zhangs ");// create a file called ssoUserId, the cookie value zhangs
/ / cookie.setDomain ( "xxxx.com ");// set cookie scope for xxxx.com so that all of the two domain names (such as www.xxxx.com, portal.xxxx.com, oa.xxxx.com) This cookie can obtain a
response.addCookie (cookie); / / write the cookie to the client
out.println ( "Login successful!");
% "

OA can read this cookie, to the user as the currently logged-on user
<% @ Page language = "java" pageEncoding = "UTF-8"%>
<% @ Page import = "javax.servlet .*"%>
"%
/ / Get single sign-on of the Cookie
Cookie [] cookies = request.getCookies ();
String ssoUserId = null;
for (int i = 0; i if ( "ssoUserId". equals (cookies [i]. getName ())){
ssoUserId = cookies [i]. getValue ();
)
)
out.println ( "SSO User Account:" + ssoUserId);
% "

If we consider the security issues, the userId encryption.

Can a URL mapping and friendly URL contain the same name?

Question In IBM WebSphere Portal, can a URL mapping and a friendly URL have the same name? For example, can you specify both a friendly URL via the Page Properties administrative portlet for your home page named "Home", and also create a URL mapping named "Home" for your home page via the URL Mapping administrative portlet?

Answer

The usage of identical names for friendly URLs and URL mappings in WebSphere Portal is not supported for usage with the same target page. Doing so can cause a redirection loop when attempting to access WebSphere Portal. Such a redirection loop can only be eliminated by avoiding the name duplication by either removing the URL mapping or the friendly URL.

Getting Page Title

Using Model SPI to get Page title

IBM WebSphere Portal uses a concept of Models for content aggregation, to track user's pages etc. The Model SPI provides access to these models. The attached code provides an example to illustrate on how to get a title of a page using model SPI in JSR 286 portlet. Here is the code snippet to get title of page

public String getTitle(PortletRequest request, PortletResponse response)
{
Context context=null;
PortletServiceHome homeObject =null;
NavigationSelectionModelProvider provider=null;
NavigationSelectionModel navSelectionModel = null;

try
{
context = new InitialContext();
homeObject = (PortletServiceHome) context.lookup("portletservice/com.ibm.portal.portlet.service.model.NavigationSelectionModelProvider");
provider = (NavigationSelectionModelProvider) homeObject.getPortletService (NavigationSelectionModelProvider.class);
navSelectionModel = provider.getNavigationSelectionModel(request, response);
}
catch (Exception exception)
{
exception.printStackTrace();
}
NavigationNode selectedNode = (NavigationNode) navSelectionModel.getSelectedNode();
//Following is commented since there is no title for page if user's locale is US English
//String pageTitle = selectedNode.getTitle(request.getLocale());
String pageTitle = selectedNode.getTitle(Locale.ENGLISH);

How to get the seedlist for the WebSphere Portal search engine in version 6.1.x Portal for either the portal collection or the WCM collection

How do I generate the output for the search seedlist in portal version 6.1.x for either the portal collection or the WCM collection?

Cause

The reason for this is to examine if there is a problem with the search engine crawler or the seedlist servlet that provides a list of documents to be crawled and indexed in the portal. This is used in debugging if it is suspected that the proper amount of documents are not indexed, or not all the correct attributes are indexed.

Answer

Follow these steps to generate the seedlist output. 1. Log in to the portal with an administrative ID 2. Navigate to the administrative pages and select this portlet: Search Administration > Manage Search 3. Within the portlet go to Search Collections > (portal/wcm collection) 4. Select this collection: 5. Edit the Portal content source: 6. Copy the URL that was automatically generated when creating the content source, and past this in a new browser window: 7. You may be asked for a log in via a pop-up. Be sure to allow this, and log in with the userid that you configured search to use. This is what you should see: 8. Save this as a web page, and submit this to support via this information.

Just JSR 168

The Java Standardization Request 168 (JSR 168) defines a portlet specification, including a contract between the portlet container and the portlet. JSR 168 is defined by the Java Community Process (JCP). The JSR 168 was co-led by IBM and Sun and had a large Expert Group that helped to create the final version which is now available. This Expert Group consisted of Apache Software Foundation, Art Technology Group Inc.(ATG), BEA, Boeing, Borland, Citrix Systems, Fujitsu, Hitachi, IBM, Novell, Oracle, SAP, SAS Institute, Sun, Sybase, Tibco, Vignette. More details about this JSR can be found at http://jcp.org/en/jsr/detail?id=168.

Important: The information provided in this analysis is provided without warranty of any kind. The analysis is intended to be an informational tool only for the reader.

JSR 168 definitions

This section provides basic JSR 168 definitions so that you can understand how JSR 168 fits into the overall portal architecture.

Portal and portlet container

A portal is a Web application which typically provides personalization, single sign-on, content aggregation from different sources, and hosts the presentation layer of different backend systems.

The main task of a portal is to aggregate different applications into one page with a common look and feel for the portal user. A portal may also have sophisticated personalization features which provide customized content to users. Portal pages may have different sets of portlets to create content for different users.

depicts the basic architecture of portals, such as a portal that is served by WebSphere Portal. A client request is processed by the portal Web application, which retrieves the portlets on the current page for the current user. The portal Web application then calls the portlet container for each portlet to retrieve its content through the Container Invoker API. The portlet container calls the portlets through the Portlet API. The Container Provider Service Provider Interface (SPI) enables the portlet container to retrieve information from the portal.

The portlet container runs the portlets, provides them with the required runtime environment, and manages their lifecycle. It provides persistent storage for portlet preferences which enables the portlet to produce customized output for different users.

Portal page and portlets

depicts the basic portal page components. The portal page represents a complete markup document and aggregates several portlet windows; that is, it combines different application user interfaces into one unified presentation. The portal page lets the user authenticate to the portal through the login dialog to access a personalized portal view. Most portal pages include some navigation mechanism to enable the user to navigate to other portal pages.

A portlet window consists of:

• Title bar, with the title of the portlet
• Decorations, including buttons to change the window state of the portlet (such as maximize or minimize the portlet) and buttons to change the mode of a portlet (such as show help or edit the predefined portlet settings)
• Content produced by the portlet (also called a markup fragment).

Figure 3 shows such a portlet window on different browsers. As you can see, the markup fragment produced by the portlet is not restricted to HTML, but can be any markup.

Portlet lifecycle

The basic portlet lifecycle is to:

1. Initialize, using the init class to initialize the portlet and put it into service.
2. Handle requests, processing different kinds of actions and rendering content.
3. Complete, using the destroy class to take the portlet out of

The portlet receives requests based on the user interaction with the portlet or portal page. The request processing is divided into two phases:

1. Action processing

If a user clicks on a link on the portlet, an action is triggered. The action processing must be finished before any rendering of the portlets on the page is started. In the action phase the portlet can change the state of the portlet.

2. Rendering content

In the render phase, the portlet produces its markup to be sent back to the client. Rendering should not change any state. It allows a page re-fresh without modifying the portlet state. Rendering of all portlets on a page can be performed in parallel.

Figure 4 depicts the request flow from the client to the portlets, and shows the action and render phases in more detail. In this example, portlet A has received an action. After the action is processed, the render methods of all portlets on the page (A, B, C) are called.

Portlet modes

Portlets perform different tasks and create content according to their current function. A portlet mode indicates the function a portlet is performing, at a point in time. A portlet mode specifies the kind of task the portlet should perform and what content it should generate. When invoking a portlet, the portlet container provides the mode for the current request to the portlet. Portlets can programmatically change their portlet mode while processing an action request.

JSR 168 defines three categories of portlet modes.

1. Modes which are required to support (same semantic as above)

Edit

Display one or more views that let the user personalize portlet settings.Help

Help

Display help views.

View

Display the portlet output.

2. Optional custom modes

About

Display the portlets purpose, origin, version, and other information.

Config

Display one or more configuration views that let administrators configure portlet settings which are valid for all users.

Edit_defaults

Set the default values for the modifiable preferences that are typically changed in the EDIT screen.

Preview

Render output without the need to have back-end connections or user specific data available.

Print

Display a view which is suitable for printing.

3. Portal vendor specific modes

These modes are only available in a specific vendor portal.

Window states

A window state is an indicator of the amount of portal page space assigned to the content generated by a portlet. The portlet container provides the current window state to the portlet, and the portlet uses the window state to decide how much information it should render. However, portlets can also programmatically change their window state while processing an action request.

JSR 168 defines the following window states:

Normal

The portlet shares the space with other portlets and should take this into account when producing its output.

Maximized

A window has more real estate to render its output than in normal window state.

Minimized

The portlet should only render minimal or no output.

In addition to these window states, JSR 168 allows the portal to define custom window states.

Data model

JSR 168 defines different mechanisms for the portlet to access transient and persistent data.

The portlet can set and get transient data in the following scopes:

Request	The request has attached data, such as request parameters and attributes, similar to the servlet request. The request can contain properties to allow extension, and client header fields being transported from the portal to the portlet and vice versa.
Session	The portlet can store data in the session with either global scope, to let other components of this Web application access the data, or portlet scope, which is private to the portlet.
Context	The portlet can store data in the Web application context, similar to servlets

The portlet can access persistent data with these scopes:

Per portlet	The portlet can store configuration and personalization data in the portlet preferences to enable the portlet to create personalized output. The portlet can define which data the user is allowed to change in the edit mode (for example, stock quotes), and which data are configuration settings can only be changed by an administrator in config mode (for example, the stock quote server).
Per user	User profile information can be read by the portlet to tailor its output towards the user (for example, show the weather of the city where the user lives).

Portlet application

All resources, portlets, and deployment descriptors are packaged together into one Web application archive (WAR) file. There are two deployment descriptors:

• All Web application resources that are not portlets must be specified in the web.xml deployment descriptor.
• All portlets and portlet related settings must be specified in the portlet.xml deployment descriptor.

Comparing JSR 168 and the IBM Portlet API

Comparing JSR 168 and the IBM Portlet API

This section gives a high level comparison between the new JSR 168 Portlet API and the IBM Portlet API. First, it covers the concepts that are similar; then, it explains some of the differences between the two.

Similarities

The following concepts are very similar in JSR 168 and the IBM Portlet API.

Feature	Similarities	Differences
Portlet modes	Both support the basic portlet modes: Edit, Help, and View.	The config mode is optional in the JSR 168. The other optional JSR 168 modes (About, Edit_defaults, Preview, Print) are not supported by the IBM Portlet API.
Window states	These window states are supported: Maximized, Normal, and Minimized.	The Solo window state is only supported by the IBM Portlet API.
Portlet lifecycle	The lifecycle life cycle is the same: init, process requests, destroy.	none
Request processing	Request processing is divided into an action phase for processing user actions and a render phase for producing the markup.	none
URL encoding	Both support creating URLs pointing to the portlet or to a resource.	none
Include servlets/JSPs	Servlets and JSPs can be included in the portlet.	none
Portlet session	Portlets can store transient information that should span requests in a session.	none
Portlet application packaging	Both package portlet applications as WAR files with an additional deployment descriptor called portlet.xml.	The portlet.xml format differs.
Expiration-based caching	The portlet can support expiration based caching.	The APIs use different mechanisms to implement this functionality. The IBM Portlet API uses a polling mechanism where the portal queries the portlet for how long the markup will be valid, whereas in the JSR 168 the portlet can attach an expiration time to each created markup. Sharing the cache entry across users is only possible in the IBM Portlet API.

Differences

The JSR 168 and the IBM Portlet API differ in the following ways.

Feature	IBM Portlet API	JSR 168
Portlet application entities	Lets you define an abstract portlet application and different instance of this portlet application as concrete portlet applications via the deployment descriptor. This allows reusing settings of the abstract portlet application and only overwriting the parts that are unique for each concrete portlet application.	The deployment descriptor follows the web.xml deployment descriptor and defines one portlet application and the portlet definitions for this application.
Portlet entity	There is one portlet object instance per portlet configuration in the Web deployment descriptor. There may be many PortletSettings objects parameterizing the same portlet object according to the Flyweight pattern, provided on a per-request basis. Changes in the PortletSettings apply to all portlet instances of this concrete portlet. The user can also have personal views of concrete portlets that are rendered using the PortletData for customization of the output.	PortletSettings and PortletData are merged into one object called PortletPreferences.
Request/Response objects	The request/response object that the portlet receives in the render call is the same as the one received in the action call.	In the JSR 168 these are two different objects.

Cross Site Request Forgery. What it is and how to work around it.

If there's a way to solve the Cross Site Request Forgery (CSRF) issue that has been highlighted by every web Security Team. Previously, normal a common filter application (J2EE Filter) that filters out Cross Site Scripting Characters from a request and response. This helped tremendously in passing the security assessment as all they have to do is define the filter on their applications and filter will do the rest.

Is there's a way to create a common standards for applications so that each applications need not to worry about Cross Site Request Forgery. Basically, their Internal Security Team requested them to put hidden keys that will be validated once the forms are submitted (for got post and get) and if the hidden keys are missing or wrong, then the form submission will fail.

Anyway, this was the first time anyone heard of Cross Site Request Forgery, so did some research.

Apparently, Cross Site Request Forgery is a form of hijacking your application session in order to fool the users into submitting invalid contents to the application and the application will process it. How does it hijack your application ? And why only now ?

Basically it works this way. Imagine you are browsing your Online Banking and you need to transmit money to your GF/WIfe/Mother or whoever. You forgot the amount to transfer and the information is actullay on your Email. So you decided to check your online email account (by going to New -> Open Window on I.E., which will share the same session with the exisitng browser). While checking your email, you saw an email from someone asking you to check a good holiday getaway. You checked the email and you find that place impressive, so you decided to click on the image on that email. And that email redirected you to a genuine looking promotion site. After your read, you closed the email and decided to transfer the money. Seems nothing happened right ? Wrong, you noticed that you have missing thousand of dollars on your account.

How did this happened ? Remember two things in these scenario :

1. You are still logged in to your online banking. Technically, your session is still alive.
   
   
2. You saw a genuine email inviting you to check out the new holiday getaway. However, when you clicked the image, apparently, the image link actually executes a javascript which will contact your bank by executing a get command with parameters such as : http://bank.example/withdraw?account=bob&amount=1000000&for=mallory Which actually withdraws from your account and transfers it to another account. And since your session is alive, this actually gets executed on your behalf. However, it looks harmless to you as you were just redirected to a vacation site, without knowing that you have just transferred thousands of dollars to another bank account.

Why only now ? It became prevalent because of the Tabs behavior of the browser. Normally, what people doe before was just to launch a new IE browser (nobody goes to New->Window.. only a few), which thereby actually separates your banking session to your email. However, with the prevalence of the tab technology, people just open up a tab, which will actually share session with your existing banking application.

There are ounces of preventions on this thing. Two of the most popular ones are :

1. Checking the HTTP Referrer.
2. Having a hidden validation key for every form submission

The problem with checking HTTP Referrer is that this can be suppressed. Some HTTPS also omits HTTP Referrer.

Hidden Validation Key is one of the solution for this. How does this work ? Basically, for every form request, the application will issue a unique key that will be validated upon the submission of the request. Since the attacker does not know the correct key, if the form is submitted with an invalid key or missing key, the application can assume that this is an attack and fail the submission of the form.

The problem with implementing this solution is that you need to modify your application to conform to this. If you are using an MVC Framework, this might not be an issue as you can have your controller issue the key and check the key before the view generates the page. However, I don't think most of the applications out there actually uses MVC framework (take .NET for example). If you are my client and you have a lot of applications available, then you need to re-write this applications to include Hidden Validation Keys.

However, there's another solution to this issue (for both .NET and Java/J2EE). The solution is to have a J2EE Filter or IHttpModule do the job for your. How does this work ?

If you are familiar with .NET and/or Java, before the request or response reaches the application, any implemented filters via J2EE Filter or IHttpModule gets executed first. On this level, Filters can check the contents of the Request or Response. They can even modify the contents of this two. If I have a Filter that will actually help me :

1. Generate a random key and store the key into the session.
2. Add this Random key as a hidden value field on the Response part of the application as part of the Form Submission.
3. When Form is submitted, I validate this key.
4. If Key is valid, pass it to the applicaiton.
5. If key is invalid, fail the submission.

This will solve the issue. And since its a J2EE Filter or IHttpModule, this can be re-used and is shareable to all applications. This mean... Taa-daaaa.. I DON'T even need to change any line in my existing applications to defeat CSRF.

However, sometimes, storing a session variable may not be a good idea, especially if you are working on an environment with Load Balancing. Sometimes, session variables get lost so there's a tendency of Form Failure not because of CSRF but because of infrastructure failure. How do you do solve this ? Well, why don't we generate a Checksum key instead.

How does this work ? It works by doing the below :

1. Read the contents of the Form Data. Based on the field names, generate a checksum with an algorithm known only to you.
2. Add this key to the form data.
3. When form is submitted, check the field names and calculate the checksum.
4. If Key is valid, pass it to the applicaiton.
5. If key is invalid, fail the submission.

Voila!!!. I don't need a session variable after all. So I told my client that this can be done.

Well, I emailed him that we can prevent CSRF without even changing your application. At most, only the configuration (web.xml or web.config) needs to be changed to include the Filter on the application.

So the filter will do this :

1. User Request for Page
2. Browser goes to the server and request for the page
3. Application sends the page to the browser.
4. However, Response Filter intercepts the response.
5. Response Filter generates an authentication key. If you used a checksum based solution, this key is a calculated checksum.
6. Response Filter saves the key to the J2EE Session, if you follow the session-based solution, otherwise this key is actually a checksum key.
7. Response Filter appends the key to the HTML Form.
8. Response Filter sends the request to the Browser.
9. Browser renders page (with the key embedded).
10. User interacts and submits the page
11. Information is send to the application
12. However, Request filter intercepts the request.
13. Request Filter checks for the authentication key
14. Request Filter Authenticates Key by comparing with the J2EE Session, if you're using a Session-based solution, otherwise Filter will validate the checksum..
15. If key is invalid, Request Filter generates a response and shows error page. Request ends.
16. If valid, Request Filter sends the information to the Application.
17. If Key is in the hidden field, hidden field is removed. This is optional and can be done in-cases where Application checks for any extra fields and invalidates the request if any extra-field is found.
18. Application processes the information.

Next would be coding part. When I have time, I will probably code on both .NET and Java and share the codes to you. It will be a simple Filter that uses Session-based solution.

Portlet Context,Portlet Config and Portal Context

PortletContext

is similar to servletConext and is used to get values declared in web.xml.
Inside doView method of your custom portlet ( implementing GenericPortlet.), you can get context param as below

getPortletContext().getInitParameter("ContextParam")

PortletContext scope is application wide.
If you set any attribute to portletContext, that would be available to all the portlets in that portlet application.

PortletConfig

PortletConfig is similar to ServletConfig and is used to get init parameters declared in portlet.xml. In servlet, we use web.xml for declaring init params and get those using servletConfig.

portletConfig data is attached to a portlet and has a scope to the portlet only.

Code sample to get portlet init parameters....

public void init(PortletConfig portletConfig) throws PortletException{

super.init(portletConfig);

portletConfig.getInitParameter("");

}

PortalContext

this gives information about portal server and other properties...

if you write renderRequest.getPortalContext().getPortalInfo()

this will give you portal name and version as per your env

for me it returned:- IBM WebSphere Portal/6.1

PortalContext has more methods to get properties... you can play with them all as and when needed

WebSphere Portal DataBases

Understanding the Portal Server Configuration
So far, you have seen and hopefully understood how to install and verify the WebSphere
Portal server. Now you will see how the Portal server’s configuration data is stored in the
default Cloudscape database and in files in the file system. If you want to configure and
maintain your portal server in a production environment then you need to have a
complete understanding of this configuration so pay close attention to this information.
As shown in the illustration above, the WebSphere Portal server will store most of the
configuration data in the Cloudscape database. The name of the database is wpsdb by
default. Different parts of the configuration are stored in different schemas in the wpsdb
database. The remaining part of the configuration (DB connections and Deployment
Descriptors for example) will be stored as property files in the file system.

What follows is a brief description of the important schema names and the type of
information that is stored in the wpsdb database schemas:
• Release, Likeminds, Feedback: These schemas store data of Pages, Portlets, Portlet
instances, Themes, Templates, Personalization rules and Policies. This data is not
modified during the portal runtime.
• Customization: This schema stores information specific to users (for example
PortletData).
• Community, Jcr: These schemas store data of shared documents and resources. This
data will be modified during runtime.
• wmm: This schema stores user registry data used to authenticate users.
Having the portal configuration in the Cloudscape database is fine for education and
demonstration purposes. However, this configuration data does not scale as user volume
increases and does not support portal cluster configuration data or multiple realms. You
need to move this configuration to a robust RDBMS (like DB2, Oracle, Sybase, MS SQL
Server or Informix for example) in production environments. You also need to move user
registry data from the Cloudscape database (stored in the wmm schema) to an LDAP
server (like IBM Tivoli Directory Server for example) in production environments.

How to take a heapdump and a javacore on a WebSphere Portal server

Sometimes taking a heapdump or a javacore on a Portal system can help to diagnose hung threads or a stalled system. A heapdump is a dump of the memory of the Java heap. A javacore provides insights into the various processing running inside of the heap at a given time.

Javacores should be taken two minutes apart in order determine if processes are hanging across intervals.

Depending on the version of Portal/WAS installed, the heapdumps and javacores are placed in different locations on the filesystem.

For Portal 5.1, the files are placed in /usr/WebSphere/AppServer
For Portal 6.0, the files are placed in /usr/IBM/WebSphere/AppServer/profiles/wp_profile

The files will be called something like heapdump434360.1198699170.phd and
javacore434360.1198699180.txt

Use these instructions to get started:

1. Find out the PID (process ID) of the Portal server by typing 'ps -ef|grep java'.
2. Type 'kill -3 '
3. Wait.
4. Verify that the heapdump and javacore were finished by checking in the appropriate directory.
5. Wait two minutes, and then run 'kill -3 '
6. Wait
7. Verify that they were created.

Accessing parameter from QueryString in IBM WebSphere Portal V6.1

This is very simple in IBM WebSphere Portal V 6.1
Consider we have url : https://localhost:60035/wps/portal/test?PhoneId=35102

Import com.ibm.ws.portletcontainer.core.impl.RenderRequestImpl


Write down code in Portlet.

public void doView(RenderRequest request, RenderResponse response) throws PortletException, IOException {


RenderRequestImpl renderRequestImpl = (RenderRequestImpl)request;
String phoneId = renderRequestImpl.getRequest().getParameter("PhoneId");
super.doView(request, response);
}

How to get path(/wps/portal or /wps/myportal) in IBM WebSphere Portal V6.1 theme

Import following object in jsp or class

import com.ibm.portal.state.accessors.url.ServerContext;
import com.ibm.wps.services.ServiceManager;
import com.ibm.wps.services.config.ConfigService;
import com.ibm.wps.state.accessors.url.ServerContextOnConfigFactory;
import com.ibm.wps.state.phases.ServerContextFactory;


ConfigService configService = (ConfigService)ServiceManager.getService(com.ibm.wps.services.config.ConfigService.class);
ServerContextFactory ctxFactory = new ServerContextOnConfigFactory(configService);
ServerContext serverContext = ctxFactory.newServerContext((HttpServletRequest)(request));

System.out.println(serverContext.getContextPath());
System.out.println(serverContext.getHomeProtected());
System.out.println(serverContext.getHomePublic());