Client secret not working in WebLogic

[dante]

Lately I tried adding a secret and realized that it is not stored properly in the unconfirmed authorization code. When I saw that this has been fixed in SECOAUTH-122 I tried again immediately and it worked perfectly in Jetty and Tomcat, but in WebLogic the rest template call in OAuth2AccessTokenSupport.retrieveToken(MultiValueM ap<String, String> form, OAuth2ProtectedResourceDetails resource) fails with code 401 "unauthorized", which leads me back to the confirm access page again and again. This is the code:

			return getRestTemplate().execute(
					accessTokenUri,
					HttpMethod.POST,
					new OAuth2AuthTokenCallback(form, resource),
					new HttpMessageConverterExtractor<OAuth2AccessToken>(OAuth2AccessToken.class,
							(List) Arrays.asList(new OAuth2AccessTokenMessageConverter())));

The accessTokenUri is "http://localhost:7001/sparklr/oauth/authorize", the form contains grant_type=[authorization_code], code=[qdTweX], redirect_uri=[http://localhost:7001/tonr/dpcom/login] and the resource contains the client secret, as expected and exactly like in Jetty or Tomcat.

This is returned in the response body:

Error 401--Unauthorized
From RFC 2068 Hypertext Transfer Protocol -- HTTP/1.1 :
10.4.2 401 Unauthorized
The request requires user authentication. The response MUST include a WWW-Authenticate header field (section 14.46) containing a challenge applicable to the requested resource. The client MAY repeat the request with a suitable Authorization header field (section 14.8). If the request already included Authorization credentials, then the 401 response indicates that authorization has been refused for those credentials. If the 401 response contains the same challenge as the prior response, and the user agent has already attempted authentication at least once, then the user SHOULD be presented the entity that was given in the response, since that entity MAY include relevant diagnostic information. HTTP access authentication is explained in section 11.

Does anybody have any idea why this fails in WLS when I use a client secret? Maybe this is a similar problem as in SECOAUTH-114, which results from a different (and most probably buggy) implementation of the filter chain in WLS.

[Dave Syer]

I think the response body is autogenerated by the appserver in this case. It may very well be that SECOAUTH-114 is relevant, but if it is then you should be able to set the new flag and have the server send a redirect instead. Did you try that (redirect-on-error="true")? If it doesn't work then the logs from the server are going to be more useful than the autogenerated response (switch on DEBUG for org.springframework.security).

[dante]

Sorry for the delay, but because of several other more important tasks I didn't have the time to investigate this further. But now here are the logs that show what happens when I configure a client secret in WebLogic.

client secret debug log.zip (spring output)
client secret live http headers.txt (cut after several loops)
client secret weblogic console log.txt (oauth output)

Please notice the warning from the client authentication cache "Unable to save client authentication because the request doesn't have a session!" - seems like WebLogic is loosing the session for some reason. Afterwards the request for a new access tokens results in the 401 decribed above:
RestTemplate - POST request for "https://localhost:7002/identityservice/oauth/authorize" resulted in 401 (Unauthorized); invoking error handler

[dante]

Solved! This is the answer: How to fix Basic Authentication issue on WebLogic 9.2/10.0/10.3 when using Spring Security

HTTP Basic Authentication on WebLogic starting from version 9.2 works not correctly. The problem is that if there is some request to your application with "Authorization" header the request will be intercepted by WebLogic itself and will not be passed to your application. WebLogic will try to make authentication itself. Such problem can occur in your application if you are using HTTP Basic Authentication with Spring Security.

The solution is to add <enforce-valid-basic-auth-credentials>false</enforce-valid-basic-auth-credentials> into the config.xml file (before closing tag </security-configuration>).

[Dave Syer]

Excellent! Thanks for following up on that.