Our Blog > Blog Detail

Web Content Viewer- Asponte Custom Skin

Actions

Writing your own custom SPNEGO filter

  • Created By: wpsadmin
  • Updated: June 5, 2015

When working with SPNEGO and WebSphere you may run into a case where the default filter options are not enough.  You can see more about the default filter here http://www-01.ibm.com/support/knowledgecenter/SSAW57_8.0.0/com.ibm.websphere.nd.doc/info/ae/ae/usec_kerb_SPNEGO_edit.html?lang=en.   The default options are as follows:

Condition Operator Example
Match exactly ==

Arguments are compared as equal.

host==host.my.company.com
Match partially (includes) %=

Arguments are compared with a partial match being valid.

user-agent%=IE 6
Match partially (includes one of many) ^=

Arguments are compared with a partial match being valid for one of many arguments specified.

request-url^=webApp1|webApp2|webApp3
Does not match !=

Arguments are compared as not equal.

request-url!=noSPNEGO
Greater than >

Arguments are compared lexogaphically as greater than.

remote-address>192.168.255.130
Less than <

Arguments are compared lexographically as less than.

remote-address<192.168.255.135

This will work for most cases but is not sufficient for more fine grained approach.  To create your own filter we will have to create our own java class, place it in the correct location and then configure it in WebSphere Application Server.

 

First step is that we have to create a class to use in place of the default HTTPHeaderFilter.  Since I was doing this for a WebSphere Portal product I did the following steps.

  1. Create a java project in RAD
  2. Add the Portal runtime library and JRE Library to the classpath
  3. Add the JAR com.ibm.ws.runtime.jar to the classpath

This got the project ready.  I then created a class and extended the default filtercom.ibm.ws.security.spnego.HTTPHeaderFilter.  That way I can avoid having to redo all of the code that would have been used to support the above filter values and still create my own filter criteria.  I overroad the following methods

But all accept for isAccepted simply added logging and called super.  This method public boolean isAccepted(HttpServletRequest request) {  is the one that does all the heavy lifting.

Once we have overridden that we can do what we need.  I first called super to see if one of the other filters caused it to kick out, and if not then I check against my items.  In my case I had to check for a subset of users who would not be part of the SPNEGO domain and reject them.  I was looking at the authorization header and if it was NTLM setting the isAccepted to false.  The way to tell it is NTLM is that it starts with TlRM.  Some other things to look for could be ip address, or browsers to reject.

 

Next you need to compile this to a jar.  Once you have the jar place it in install_path/AppServer/lib/ext .   You must do this on both the deployment manager as well as the nodes.  Once you have placed it there restart the deployment manager is it will verify the class is correct as you enter it.  To edit this in administrative console page, click Security > Global security. From Authentication, expand Web and SIP Security, and then click SPNEGO web authentication. Under SPNEGO Filters choose the filter to edit.  then in the Filter Class: setting set the full package and classname of your custom filter.

 

Synch all nodes and restart everything and you should now have a functional custom SPNEGO HTTPHeaderFilter.

Contact Form- Asponte Custom Skin

Actions

Contact Us

*
*


Submit
Call Us 888-926-9434
Complementary Content
${loading}