WSO2 Identity Solution, v1.5 : Java Servlet Filter Developer Guide : Part I

Introduction

This servlet filter org.wso2.solutions.identity.relyingparty.servletfilter.RelyingPartyFilter can be used with a servlet based web application to provide information card and OpenID login to that application.The Part I of this guide explains how you can add Information Card support to a relying party web application. The developer should follow the steps described below in intgrating this servlet filter:

Configuration Steps

Step 1 : Add the servlet filter to your application

Include the following entry in the web.xml file of the application:


    <filter>
        <filter-name>TokenValidator</filter-name>
        <filter-class>org.wso2.solutions.identity.relyingparty.servletfilter.RelyingPartyFilter</filter-class>
        	<init-param>
	    	    <param-name> ................ </param-name>
		    <param-value> ............... </param-value>
  		</init-param>
		<init-param>
			......................
  		</init-param>
			......................
			......................
    </filter>
	
    <filter-mapping>
        <filter-name>TokenValidator</filter-name>
        <url-pattern>/*</url-pattern>
    </filter-mapping>


Add the following as init-params to the web.xml

ParameterName Required Description
Keystore Yes Relative path to the keystore holding private key
StorePass Yes Password to the keystore holding private key
KeyAlias Yes Private key alias
KeyPass Yes Private key pass
StoreType Yes Store type of the keystore holding private key - e.g. JDK
TrustedIdP.KeyStore Relative path to the trusted keystore
TrustedIdP.StorePass If TokenValidationPolicy is NOT Promiscuous Trust store password
TrustedIdP.StoreType If TokenValidationPolicy is NOT Promiscuous Trust store type
MultiValueClaimsPolicy No - default applied Must be either MultiValueClaimsAllowed or MultiValueClaimsNotAllowed. Default is MultiValueClaimsNotAllowed
IssuerPolicy No - default applied Must be one of SelfAndManaged, Self, Managed. Default is self and managed
TokenValidationPolicy No - default applied Must be one of Promiscuous, WhiteList, BlackList, CertValidate. Default is CertValidate. Please read more about this below.
WhiteList Yes, if TokenValidationPolicy is WhiteList This is required to indicate the list of allowed DNs. If not specified in WhiteList mode none of the users can login
BlackList Yes, if TokenValidationPolicy is BlackList This is required to indicate the list of rejected DNs. If not specified in BlackList mode all users who pass CertValidity can login


TokenValidationPolicy

There are 4 modes of token validations.


Step 2 : Add the information card login page


The user login page must contain a form with an object tag as shown below:
   <form name="frm" id="frm" method="post" action="InfoCardLogin.action">  
		<input type="hidden" name="InfoCardSignin" value="Log in" /><br/>
		<OBJECT type="application/x-informationCard" name="xmlToken">
			<PARAM  Name="tokenType"
					Value="urn:oasis:names:tc:SAML:1.0:assertion">
			<PARAM  Name="requiredClaims"
					Value="http://schemas.xmlsoap.org/ws/2005/05/identity/claims/privatepersonalidentifier">
			<PARAM Name="issuer" value="http://schemas.xmlsoap.org/ws/2005/05/identity/issuer/self">
		</OBJECT>
  </form>

The object tag here is the standard information card object as defined here .

It is important that you include the hidden field called "InfoCardSignin" with the value "Log in". The filter will process the HTTP POST request to extract the token sent when this request parameter is available.



Step 3 : Add the following jars to your classpath


Step 4 : Obtain the information in the verified token and process

The results of token processing will be available as attributes in the ServletRequest object.

To indicate whether token verification was successful or not there will be an attribute by the name "org.wso2.solutions.identity.rp.State". On successful verification value of this attribute will be "success". Otherwise it will be "failure".

The ServletRequest will also contain a set of attrbites by the names of the claims (the part of claim URI after the final "/")

with their values.

These values can be used by the developer to initiate a user session in a web application.