lekkimworld.comJava

Using the IBM Connections API from other languages using custom certificates

Mon, 04 Jun 2012 06:38:36 GMT

I was reading up on some stuff in the IBM Connections REST API during the weekend and came across a post titled Using IBM Connections API in different programming languages on how to use the REST API from other languages than JavaScript from within IBM Connections. The approach there is very nice and quite valid but it fails to mention what to do if the SSL certificate of the API endpoint either isn't trusted or isn't certified using a "known" root certificate. In this case "known" means to the Java runtime you're using or the runtime of any other language for that matter. Here I'm only dealing with Java though.

By default the java.net classes will not allow a SSL connections to a server using a unknown/untrusted certificate but there are ways around that. Of course the best is always to make sure that the certificate of the server may be validated by the Java keystore (including intermediate certificates) but for testing - or if you know what you're doing - simply ignoring the certificate test can be beneficial. Below is some code showing how to configure the SSL runtime to ignore the certificate and hostname checks. The code is a static configuration method and I deem it pretty readable. The code allows *all* certificates but could pretty easily be locked down to be more restrictive if need be.

private void enableSelfSignedCerts() throws Throwable {
  TrustManager[] trustAllCerts = new TrustManager[] { 
    new X509TrustManager() {
      public java.security.cert.X509Certificate[] 
        getAcceptedIssuers() {
        return null;
      }
      public void checkClientTrusted(X509Certificate[] certs,
          String authType) {
      }
      public void checkServerTrusted(X509Certificate[] certs,
        String authType) {
      }
    }
 };

 SSLContext sc = SSLContext.getInstance("SSL");
 sc.init(null, 
         trustAllCerts, 
         new java.security.SecureRandom());
  HttpsURLConnection.
    setDefaultSSLSocketFactory(sc.getSocketFactory());

  // Create all-trusting host name verifier
  HostnameVerifier allHostsValid = new HostnameVerifier() {
    public boolean verify(String hostname, 
      SSLSession session) {
      return true;
    }
  };
  
  // Install the all-trusting host verifier
  HttpsURLConnection
    .setDefaultHostnameVerifier(allHostsValid);
}

Show 'n Tell Thursday: Maximizing tabs in DDE (20 October 2011)

Thu, 20 Oct 2011 07:24:20 GMT

It has been a looooooooooooooooong time since I did a SnTT but I found it fitting for this week. The tip is short and very straight forward but will make it easier and more productive for you to work in Domino Designer on Eclipse (DDE).

If you are like me like the navigator in DDE is on the left, and the outline/controls/data views are on the right. You realize that you do not have much space left for code in the center editor. Bummer! :-( To help remedy that you may either minimize or close the views on the right but that really isn't ideal as it takes time and some times you need the views e.g. for XPages work. As an alternative you could figure out which views you use for what tasks and create custom perspectives in DDE for those tasks which isn't for the Eclipse-superuser. You could also choose the easy solution - simply maximize the editor.

Maximizing the editor is easy. You simply double-click the tab or press Ctrl-M to make the editor go fullscreen. When done you simply double-click the tab again or press Ctrl-M to return it to being "in the middle". Easy and quick.

Hope it works as nicely for you as it does for me.

A TAI code example

Fri, 10 Jun 2011 12:06:58 GMT

To complete my series posts on writing Trust Association Interceptors (TAI's) for Websphere Application Server I wanted to show a real-life example. Not a good example necessarily but an example never the less... :-)

The below example is a very simple TAI that simply does the following:

The initialize() method reads a cookie name from the configuration done in the Websphere Application Server ISC. It illustrates how you can configure a TAI externally without having to hard code it.
The isTargetInterceptor() method looks at the request and sees if a cookie with the configured name is available. If yes it continues to process the request and if not it aborts processing (from the TAI point of view).
The negotiateValidateandEstablishTrust() method does the actual work by simply telling WAS that the username of user is the value from the cookie.

As you see writing a TAI is very simple but extremely powerful. Imagine what could be done if you did SSO between Websphere Application Server and Lotus Domino.

import java.util.Properties;

import javax.servlet.http.Cookie;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;

import com.ibm.websphere.security.WebTrustAssociationException;
import com.ibm.websphere.security.WebTrustAssociationFailedException;
import com.ibm.wsspi.security.tai.TAIResult;
import com.ibm.wsspi.security.tai.TrustAssociationInterceptor;

public class ExampleTAI implements TrustAssociationInterceptor {
   // declarations
   private String cookie = null;
   
   @Override
   public void cleanup() {
   }

   @Override
   public String getType() {
      return String.format("Example TAI %s", this.getVersion());
   }

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

   @Override
   public int initialize(Properties props) 
      throws WebTrustAssociationFailedException {
      System.out.println("ExampleTAI.initialize()");
      
      // read properties from configuration in WAS
      this.cookie = props.getProperty("cookieName");
      
      // return 0 to indicate success
      return 0;
   }

   @Override
   public boolean isTargetInterceptor(
      HttpServletRequest req) 
      throws WebTrustAssociationException {
      System.out.println("ExampleTAI.isTargetInterceptor()");
      for (Cookie c : req.getCookies()) {
         if (c.getName().equals(this.cookie)) return true;
      }
      return false;
   }

   @Override
   public TAIResult negotiateValidateandEstablishTrust(
      HttpServletRequest req, 
      HttpServletResponse res) 
      throws WebTrustAssociationFailedException {
      System.out.println("ExampleTAI.negotiate...()");
      for (Cookie c : req.getCookies()) {
         if (c.getName().equals(this.cookie)) {
            // send 200 to signal we're okay
            return TAIResult.create(HttpServletResponse.SC_OK, 
                c.getValue());
         }
      }
      
      // not authenticated
      return TAIResult.create(HttpServletResponse.SC_UNAUTHORIZED);
   }

}

New version of the Java UI API Exerciser available from OpenNTF

Tue, 07 Dec 2010 13:27:22 GMT

A new release of the Notes Java UI Exerciser project has been released on OpenNTF (OpenNTF Release: Notes Java UI APIs in 8.5.2) by our friends on the Java UI team at IBM one of whom I'm lucky enough to co-present with at Lotusphere. Check it out!

The Next Release of Java: Java JDK 7, out mid-2011

Fri, 22 Oct 2010 06:47:56 GMT

News from JavaOne:

Mark Reinhold confirmed that "Plan B" is now the plan of record for the next release of Java, with JDK 7 scheduled for mid-2011, with support for other languages on the JVM (InvokeDynamic) and many small improvements (parts of Project Coin). Things that don't make it into JDK 7 are planned for JDK 8, including Project Lambda and Project Jigsaw, scheduled for late 2012. Markus Eisele, software architect, provides details about Java SE 7 and Java SE 8.

Janice J. Heiss: Plan B Wins

How to extend Notes 8: New version of the demo application

Tue, 24 Aug 2010 17:51:38 GMT

I just posted an update to the demo application for my Extending Notes 8 series of posts. The demo application is discussed in more detail in my previous post (How to extend Notes 8: LiveText demo application). The issue was that I had a button to create a demo e-mail in the UI which made the plugin depend on the Notes Java UI API which was added in Notes 8.5.1 and hence meant that the demo application wasn't installable on previous Notes versions... :-(

To remedy that I built an new version where the button using the offending API is added from an Eclipse plugin fragment and using a custom extension point (if you're running Notes 8.5.1+). More on that approach at a later date. For now you may install the new version using the updated widget descriptor (extension.xml) (simply drag the link to your MyWidgets sidebar plugin).

If you do an update - which there's absolutely no reason to if it already works for you - the only way to tell is by verifying that the version number at the bottom of the sidebar application is changed to 1.0.1.

That's all for this post. All the posts in the series may be found under the extending_notes8 tag.

How to extend Notes 8: LiveText demo application

Fri, 06 Aug 2010 10:54:23 GMT

The day before yesterday I posted the first summary post in my Extending Notes 8 series with a complete end-to-end approach to dynamically adding LiveTex recognizers. As part of that post I uploaded a demo application (plugin) but I didn't add a screenshot so I thought I'd remedy that.

As you can see the plugin has a small welcome text and two buttons. You'll also see a textbox to hold any exception (not that I'm expecting any) that might be raised as part of adding the recognizer and content type. You may use the two buttons to easily create a demo e-mail for use with the added LiveText stuff. The left button creates the e-mail in the UI (using the new handy Java UI classes) and the right one simply sends the e-mail to you in the backend. The latter is very handy for testing as the e-mail needs to be in read mode for the LiveText sub-system to kick in.

I've put a compiled version of the plugin on my update site and tthe plugin may be installed by dragging this extension.xml file to your MyWidgets sidebar panel (policy permitting).

That's all for this post. All the posts in the series may be found under the extending_notes8 tag.

How to extend Notes 8: case insensitive LiveText patterns

Thu, 05 Aug 2010 12:11:33 GMT

When you start to do a lot of LiveText recognizers you find yourself wanting to do more advanced stuff with your regular expressions. For instance you might want to do case insensitive patterns or use some of the others regular expression modifiers. This post will show you how to do this.

By default the regular expressions you specify for your recognizers are case sensitive. This is normally fine unless you really want it to be case insensitive. Since the LiveText engine is in Java you may use the supported Java modifiers for your regular expressions. Normally the modifiers are specified when you "compile the pattern" in Java (java.util.regex.Pattern.compile(pattern, modifiers)) but as you don't have access to this process you can't do that.

There is however another way...

You can embed some modifiers in the pattern such as Pattern.MULTILINE, Pattern.UNICODE_CASE, Pattern.DOTALL and most of all Pattern.CASE_INSENSITIVE! You embed the modifier in the start of the pattern. So instead of doing a case insensitive pattern like this (to recognizer "lotus" and "Lotus"):

[Ll]otus

you do

(?i)lotus

Cool isn't it?

The following modifiers are supported in Java though not all makes sense for LiveText:

Pattern.CASE_INSENSITIVE = (?i)
Pattern.MULTILINE = (?m)
Pattern.DOTALL = (?s)
Pattern.UNICODE_CASE = (?u)

Please bear in mind that it probably only makes sense to use DOTALL and CASE_INSENSITIVE.

That's all for this post. All the posts in the series may be found under the extending_notes8 tag.