0

I have some Java code that needs to authenticate against a Sharepoint server running NTLM authentication. I have this code running fine on the command line in my IDE, but when I deploy it within Liferay as a portlet, it's just failing with 401 Unauthorized.

The code is exactly the same except in how it's invoked. One is during the doView() portlet method (portlet render phase), and the other (which works) is from a public static void main method.

I set the Jespa logging at level 4 to see output. In the NetBeans IDE:

HttpPeer: state=ST_SENT
HttpPeer: state=ST_RECEIVED status=401
NtlmSecurityProvider: null
HttpPeer: state=ST_SENT
HttpPeer: state=ST_RECEIVED status=401
NtlmSecurityProvider: NTLM2 Session Security key negotiated successfully
NtlmSecurityProvider: Initiator negotiated NTLMv2
HttpPeer: state=ST_SENT
HttpPeer: state=ST_RECEIVED status=200

In Liferay logs:

HttpPeer: state=ST_SENT
HttpPeer: state=ST_RECEIVED status=401
NtlmSecurityProvider: null
HttpPeer: state=ST_SENT
HttpPeer: state=ST_RECEIVED status=401
18:37:58,578 ERROR [SharepointListPortlet:76] 
java.security.PrivilegedActionException: our.portlet.util.HttpException: 401 Unauthorized
    at java.security.AccessController.doPrivileged(Native Method)
    at javax.security.auth.Subject.doAs(Subject.java:396)
    at jespa.security.RunAs.runAs(RunAs.java:261)
    at jespa.security.RunAs.runAs(RunAs.java:269)

It's probably something simple, but I can't put my finger on it. I've looked through all the Jespa sample code and found nothing. Of course Jespa is a commercial product and I'm just evaluating it, so I can't pay for support. If anyone has any suggestions, I'd be grateful.

Mick Sear
  • 1,549
  • 15
  • 25
  • what is the application server that you're using for Liferay? It appears to be specifying a security policy file in the start up. – David O'Meara Mar 16 '11 at 23:42
  • It's Tomcat - just the standard Liferay bundle. Here's the command: – Mick Sear Mar 17 '11 at 10:57
  • wrong direction I think. check the API for `PrivilegedActionException` and it says it is a wrapper for another Exception, so you'll need catch it and and add `getException()` to the logging to find the root cause. – David O'Meara Mar 17 '11 at 11:14
  • Thanks , but that's not it. The wrapped exception is the HttpException above. The issue is something to do with the NTLM challenge-response. Something is causing it to fail in one environment and not the other. The code gets invoked with the right parameters in both cases. – Mick Sear Mar 17 '11 at 12:05
  • yep, I realised that after I wrote it. Sorry, just guessing now. – David O'Meara Mar 17 '11 at 12:32
  • I've narrowed this down further - it's not Liferay or Tomcat. However, Liferay is running in an Ubuntu VM. java version "1.6.0_24" Java(TM) SE Runtime Environment (build 1.6.0_24-b07) Java HotSpot(TM) 64-Bit Server VM (build 19.1-b02, mixed mode) It works on my Mac with exactly the same files and JARs on the classpath. So, it's either something to do with the VM or the Java version. Mac Java version is java version "1.6.0_22" Java(TM) SE Runtime Environment (build 1.6.0_22-b04-307-10M3261) Java HotSpot(TM) 64-Bit Server VM (build 17.1-b03-307, mixed mode) – Mick Sear Mar 17 '11 at 15:57
  • Is there anything unusual in the jespa log file? – Sam Backus Aug 09 '11 at 16:08

1 Answers1

0

IOPLEX support will still help you even if you have not purchased the product.

Regarding your question, instead of using javax.security.auth.Subject to supply credentials, try supplying the credentials using "header properties". Maybe your Liferay thingy is creating new Threads and the Subject based credentials are getting dropped. This feature is not documented anywhere (and as such technically it is not supported) but look at examples/HttpGetWithHeaderProperties.java.

squarewav
  • 383
  • 2
  • 8