Process of User Login

Process of User Login
Have you recently been to a hi-fi apartment with lots of security? Chances are you had to go through a few steps before you were let in. First the watchman stops you and asks you for an id or who you are. Then he communicates this over intercom to announce your arrival. And your final stop was probably at the reception to get directions for the block/person you are looking for.

What has this got to do with our project? Well, a similar security process happens from the point the user accesses the application url to the time when user sees the desired page.

The three gates it passes through are
1. SiteMinder authenticates (Watchman) 2. TAI establishes trust (Intercom) 3. LoginFilter redirects the user (Reception)
Let us look at each of these in detail

SiteMinder:

SiteMinder is a proxy authentication server which intercepts every request and forces user authentication for protected resources. A web agent is installed in the client system and this web agent intercepts every url.

Whenever the user tries to access a protected url configured in SiteMinder, Siteminder checks if the user session already exists. If not, then it shows the login page (in our project it is login.fcc) to the user. When the user enters the credentials and submits the form, this web agent collects the user credentials from login.fcc form and passes on to the SiteMinder. SiteMinder authenticates the user against LDAP, checks the user account status, password status and redirects the user to the target url set in the login.fcc file.

TAI:

Why TAI
The TAI interface provides a mechanism by which WebSphere Application Server enables an external component(here SiteMinder) to authenticate the user and then assert the identity to the WebSphere Application Server Web container.SiteMinder authenticates the user and then simply informs WebSphere Application Server as to the end-user's identity. SiteMinder does this by setting the user information in header. The TAI extracts this information and then returns the user's ID to WebSphere Application Server, which then queries the registry as it normally would, but does not validate the user's password.
In our project , the custom TAI used is com.chartis.gp.tai.CISiteminderTAI which implements the class com.ibm.wsspi.security.tai.TrustAssociationInterceptor .This class uses header information from request 'sm_user' to extract the user id and establishes a trust session for the user.

How is it configured
1) Take the source files from project CustomTAI. 2) Export jar and place this jar in IBM\WebSphere\PortalServer\shared\app 3) Go to Admin Console
In the admin console, select Security->Secure Administration, applications and infrastructure->Web Security->Trust Association -> Interceptors ->New TAI
Class Name :com.org.tai.CustomSiteminderTAI
4)Restart the server

LoginFilter:
Before I go into the details of what this filter does and how it is configured, let me give you the background as to why this was introduced inour project. Not all projects would need this step. It was because our project had to do some pre-processing logic before logging the user.
SiteMinder by default directs the user to dashboard page set in the target parameter passed to it. But if the user is not upgraded, the user should be redirected to upgrade profile page. Internal users have to be redirected to ecomm admin home page. This logic of determining the user type and status before the user logs in is done in LoginFilter.
Once the TAI is established with the portal server, this filter is invoked by the portal server.There are two filters that can be used to achieve this functionality ImplicitLoginFilter and ExpliciLoginFilter.

ImplicitLoginFilter is used when when the user already has received a security context by the WebSphere Application Server, but is not yet logged in to WebSphere Portal.

ExplicitLoginFilter is used when user logins either using the login portlet service (which is also used by the default login portlet) or the login URL.

In our project, ImplicitLoginFilter is used. The class created for this is com.org.CustomLoginFilter. It implements the IBM class com.ibm.portal.auth.ImplicitLoginFilter.

How is it configured
To configure LoginFilter in local m/c follow these steps
1) Take the source files from project CustomLoginFilter. 2) Export jar and place this jar in IBM\WebSphere\PortalServer\shared\app 3) Go to Admin Console
a. Navigate to:
Resources ->Resource Environment ->Resource Environment Providers -> WP Authentication service ->CustomProperties
b. Create the following key value pair login.implicit.filterchain = com.chartis.gp.login.LoginFilter (Please note the case).
4)Restart the server.

Further readings:
http://www.ibm.com/developerworks/websphere/library/techarticles/0905_buchwald/0905_buchwald.html
http://publib.boulder.ibm.com/infocenter/wpdoc/v6r1/index.jsp?topic=/com.ibm.wp.ent.doc_v6101/admin/adauthflt.html
http://www.ibm.com/developerworks/websphere/techjournal/0508_benantar/0508_benantar.html

Courtesy : Anju Jain