0

I have created a ContainerRequestfilter and successfully made it trigger. Now I'd like acccess the UserPrincipal I have set before in a grizzly HttpServerProbe like this:

import com.sun.jersey.spi.container.ContainerRequest;

@Override
public ContainerRequest filter(ContainerRequest request) {
  Principal principal=req.getUserPrincipal();
}

Instead a "UnsupportedOperationException" is thrown. It looks like the ContainerRequest does not pick up the UserPrincipal from the modified request.

The modification is done via

import org.glassfish.grizzly.http.server.Request;

...

public void onRequestReceiveEvent(
  HttpServerFilter filter,Connection connection, Request request) {
  Principal principal=getPrincipalFromRequest(request);
  request.setUserPrincipal(principal);
}

The issue is how to to transport the Principal information from the HttpServerProbe to the ContainerRequestFilter. The org.glassfish.grizzly.http.server.Request has the security information (in this case SSL Client certificate information) while the com.sun.jersey.spi.container.ContainerRequest initially does not provide it.

Unfortunately I have also not found a way to set the SecurityContext in the HttpServerProbe. In the ContainerRequestFilter i could do it but the necessary Principal information is not available as I would have expected.

I am using Jersey 1.17 and Grizzly 2.3.5

the following links where all somewhat related to the issue, but none was giving a clue what may be the reason for the above error:

http://www.solutionoferror.com/java/use-containerrequestfilter-in-jersey-without-web-xml-79849.asp

Jersey ContainerRequestFilter not triggered

http://subversion.jfrog.org/artifactory/public/tags/2.1.0/rest/src/main/java/org/artifactory/rest/common/RestAuthenticationFilter.java

http://sites.gbif.org/common-resources/gbif-common-ws/xref/org/gbif/ws/server/filter/AuthFilter.html

http://2rdscreenretargeting.blogspot.de/2012/06/secure-jersey-with-oauth2.html

What needs to be done to access the principal / set the security context with the principal in a way that HttpServerProbe and ContainerRequestFilter cooperate in assembling this info ?

Community
  • 1
  • 1
Wolfgang Fahl
  • 15,016
  • 11
  • 93
  • 186

1 Answers1

2

Jersey/JAX-RS expects SecurityContext to be set before you can retrieve any information about principal, user roles etc. Usually, in Jersey, this is done by dedicated ContainerRequestFilter. Take a look at the sample filter from one of our samples: SecurityFilter.

After this, you can inject SecurityContext (using @Context) into your resources or other providers such as filters. You can then also call containerRequest.getUserPrincipal() without getting an UnsupportedOperationException.

EDIT 1

If you need to obtain Principal object in grizzly level you can inject the current Request into your filter and then retrieve the value in filter method.

@Context
private ThreadLocal<Request> request;
Michal Gajdos
  • 10,339
  • 2
  • 43
  • 42
  • Thank you for the reply - I have modified the question to be more clear. I would happily set the SecurityContext if i could only get the Principal information that is already available over to the ContainerRequestFilter – Wolfgang Fahl Nov 21 '13 at 06:34
  • I have worked around the issue now by creating a PrincipalCache - the HttpUnitServerProbe adds the Principal by it's name into the cache and adds a header info to the request. This way the ContainerRequestFilter can pick up the Principal from the cache by using the information from the modified request header. Given the example you mentioned the BasicAuth is also possible when there is no principal info in the Cache. – Wolfgang Fahl Nov 24 '13 at 09:24