top button
Flag Notify
    Connect to us
      Facebook Login
      Site Registration Why to Join

Facebook Login
Site Registration
Print Preview

Possible to expose a Tomcat Realm instance through JNDI ?

0 votes
56 views

In my web app, I'd like to re-use the (server-wide) Tomcat Realm that is already being used for HTTP Basic authentication but couldn't find a way how to get hold of the actual Realm instance.

I spent quite some time looking for a solution (complicated by the fact that most Google hits actually referred to the LDAP authentication realm) but found none. Is there a "config-file-only" solution or do I need to dig into the Tomcat source code and come up with my own JNDI ObjectFactory to achieve this ?

posted Jun 11, 2013 by anonymous

Share this question
Facebook Share Button Twitter Share Button Google+ Share Button LinkedIn Share Button Multiple Social Share Button
What are you actually trying to accomplish? Do you want to authenticate a user, or get information about an authenticated user?

1 Answer

0 votes

I don't think there is a HTTP Basic authentication realm. The authentication type is declared in the of your web.xml and can be used in conjunction with a number of different realm implementations.

Exactly what do you mean by re-use? Does this mean you are doing authentication from within your web app?

answer Jun 11, 2013 by anonymous
My application is exposing a SOAP service (through Spring-WS servlet) for which I want to do method-level access control. Since the service endpoint already uses container-based HTTP Basic authentication, I'd
like to reuse the realm implementation (and configuration, obviously) my own code to get hold of the user's roles.

I just found HttpServletRequest#getUserPrincipal() , maybe I can just downcast the result to org.apache.catalina.realm.GenericPrincipal and invoke getRoles() on this... ugly, but well... ;)
I think I now understand your issue. I was faced with a similar problem and could not figure out how to get the roles of an authenticated user through the servlet API.

It seems to only allow the question 'request.isUserInRole(role)'. But does not seem to provide a way to get a list of roles that the user is in.

I used a kludge whereby I defined the valid roles in a context init parameter (bad duplication of effort). Then used 'request.isUserInRole(role)'. I did not think to cast the 'request.getUserPrincipal()' return value.
Similar Questions
+1 vote

I want to access the JNDI Directory context in Tomcat8. I've used DirContextURLStreamHandler class which was in Tomcat 7. But now that has been removed.

Can someone tell me how can I access the JNDI Directory Context in Tomcat 8?

+1 vote

I write my own realm implementation for Tomcat 7.x. In the method Principal authenticate(X509Certificate[] certs) I'd like to read request headers. My authentication would be based on client certificate + custom http request value. Is it possible?

The method authenticate is called in
SSLAuthenticator.authenticate(Request request, HttpServletResponse response, LoginConfig config)

But I do not see that the Request object is passed to realm instance. Is there something similar like WebServiceContext that is used for WS?

...
 @Resource
 WebServiceContext wsctx;
 MessageContext mctx = wsctx.getMessageContext();
 HttpServletRequest request = (HttpServletRequest) 
mctx.get("javax.xml.ws.servlet.request");
...
+4 votes

Is there any way to not have the password visible in the realm for example for active directory realm?

+2 votes

I'm running a server with multiple instance of tomcat each instance has some apps deployed & accessed with host:port, like

myhost.com:7777/app1
myhost.com:8888/app2
myhost.com:9999/app3

Is there any way to hide the port from users & making app URL simpler with keeping multi instance? like this or any thing near

app1.myhost.com
app2.myhost.com
app3.myhost.com

Useful Links with Similar Problem
Contact Us
+91 9880187415
sales@queryhome.net
support@queryhome.net
#280, 3rd floor, 5th Main
6th Sector, HSR Layout
Bangalore-560102
Karnataka INDIA.
QUERY HOME
...