File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
http://aspose.com/file-tools
The moose likes Tomcat and the fly likes Tomcat - Domain Authentication Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Products » Tomcat
Bookmark "Tomcat - Domain Authentication" Watch "Tomcat - Domain Authentication" New topic
Author

Tomcat - Domain Authentication

Dan Josephs
Greenhorn

Joined: Jun 25, 2012
Posts: 4
I have a webserver running tomcat and the entire webserver is located outside of my domain but on the same network. I need to be able to access files (images, pdf) that are located within my domain. I don't want users to have to login or authenticate, I want the webserver or Tomcat configuration to pass the authenticate/certificate and grant the website access to those files without any user input. I am just not sure how to do this? Is there a tomcat configuration that I can use? I wasn't sure if this request was similar to using Tomcat Realms.

Thanks
Tim Holloway
Saloon Keeper

Joined: Jun 25, 2001
Posts: 15964
    
  19

Welcome to the JavaRanch, Dan!

When you want access to resources on another domain, or even another server within the same domain, it's that other server who makes the decision about accessibility. Tomcat only controls access to resources that that Tomcat server itself serves up.

While your question isn't entirely clear, if you have a number of servers all in the same domain, you can design that domain for Single Signon (SSO). Each server in that domain would authenticate and authorize with a central security service or repository. Tomcat has several Realm plugins that can assist in that.

A security domain doesn't necessarily have to be the same thing as a DNS domain, so just because you have servers in the "bar.com" and "foo.org" domains doesn't mean that they cannot share the same security services. They just might have to work a little harder at it, is all.


Customer surveys are for companies who didn't pay proper attention to begin with.
Dan Josephs
Greenhorn

Joined: Jun 25, 2012
Posts: 4
Hi Tim,
Thanks for replying and thanks for the welcome. I'm not sure I articulated the problem well. We have a domain setup, lets call it "ourdomain". We have several computers and 2 servers on this domain. One of the servers is called SBS. We also have a webserver that is located on the same network but NOT located within "ourdomain". We correctly setup all of the permissions for SBS so the webserver can properly access its files. For example, when you log into the webserver and point the browser to "file://///sbs/images/003505.jpg" the browser will correctly display the image. So I know the permissions are setup correctly. But when I try to access that same file within the website which is run by Tomcat, it can't find or access the file. I'm not sure if this helped clear up my issue let me know if you still think this is a permission issue on the SBS server.

Thanks
Tim Holloway
Saloon Keeper

Joined: Jun 25, 2001
Posts: 15964
    
  19

You are confusing Windows domains with "real" domains.

When you use the "file:" protocol in your web browser URL, what you are doing, in effect, is making a local filesystem request (in this particular context, LAN shares count as local). Internally, the browser calls the OS open() function, reads the file, sends it through the browser's page formatter and renders the formatted results in the browser window. Unless of course you're running IE and the format is an external program such as Excel or PDF, where because of legal constraints an external application must be opened instead.

When you use the "http:" or "https:" protocol, an entirely different mechanism is used and the security rules are different at well. In this case, instead of a filesystem open(), a network socket pair is opened. On one of those sockets, an HTTP-formatted data stream is sent to the socket's destination port, which is a DNS domain name (NOT a Windows domain name) and a port number extracted from the URL. If no port number is explicitly given, a default port is assumed: 80 for http, 443 for https. The web server processes the request, generates an HTTP-format response output stream and sends it back to the other port that the client opened - its response port. The browser will then send the response data to the page formatter and at that point, everything is just like it was if it had come through a file.

Normally, the security system used on an Internet domain is not secured by Windows security because except in rare cases, Windows security doesn't work on the Internet, only on a LAN. You wouldn't really want it to, anyway. Your LAN security administrator would not be amused at the thought of having to create and maintain Active Directory accounts for everybody in the world that ever wanted to visit your public webservers. Especially since I run Linux, not Windows. So instead, webservers have their own security managers, usually on a per-application basis. In the case of J2EE, that would be the container managed security Realm system unless some "clever" person had designed their app to do roll-your-own security.

Despite all these differences, it is possible to reconcile, although it's not quite a walk in the park. There is a Tomcat Realm that can hook into Windows LAN security and use it as Single Signon security, although each user's browser requires a registry tweak to use it. If you don't need Single Signon, you can also just use the LDAP realm and authenticate against Active directory.

Having said all that, however, your real problem is not quite the same thing. Just because the client has LAN file access to a file, doesn't mean that the Tomcat server does. The Tomcat server is operating as a completely different user with its own set of security privileges, and that's even more important than whether or not it's in the same Windows Domain or not. Windows allows Domains to be friends with each other, but if the file in question doesn't have compatible access, Tomcat still cannot open it and use it, friend or not.

Finally, one last note. A web page does not usually get all its content from a single server. Each external javascript, CSS, image, and so forth has its own independent URL and is resolved by an independent request. If the client has direct file access guaranteed, you can put a "file:////server/share/path" URL in a hyperlink and the client will obtain that file directly, regardless of whether Tomcat has rights (or an access path) to it or not.





Dan Josephs
Greenhorn

Joined: Jun 25, 2012
Posts: 4
Tim,
I can't thank you enough for taking the time to help me resolve my issue. If you ever need me to write a recommendation, I am your man. Having said that, my issue is still unresolved. I read your reply a few times and I just need to clarify a few things.

1. When I was doing my "file:///sbs.... " test from the browser, it wasn't from a client computer, I was using the browser on the web server to verify if the web server had access to those files. But I do understand that it is making a local filesystem request so that is probably not the best test.

2. The code that I am having a problem with is an ImageServlet that I created for our website running on our webserver. The ImageServlet takes input from the request object to create a file path which will return an image to the browser. The images are located on another server on the same LAN but different domains.

3. The servlet code worked fine until we moved the web server outside of our domain for security reasons. In case anyone hacked our webserver, we didn't want a direct connection to the main server in our office.

I wasn't sure if that information helped in clarifying if this is a Tomcat security issue or Windows security issue. This isn't an intranet web site so, single sign-on isn't an option. I was hoping to grant Tomcat the security rights to access the images on the other server.

Again Tim, thank you for all your help!

Dan
Tim Holloway
Saloon Keeper

Joined: Jun 25, 2001
Posts: 15964
    
  19

No problem.

Using a browser on your server to look at a file has one small problem. Well, 2, in the case of my servers, since they normally don't run windowing systems, but that's another story. The main problem, however, is that the user ID that the browser is running under is (hopefully!) not the same user ID that the Tomcat server runs under and therefore may not have identical file access privileges.

I'm not certain, since I tend to miss details on stuff like this, but it's possible that you are running into the applet sandbox. Java isn't quite as trusting as certain other systems Who Shall Remain Nameless, and one of the cases where trust is hard to come by is when an applet is loaded from one server but attempts to access resources on a different server. Only signed servlets can avoid being sandboxed, but signed applets are a real pain.

You might be able to setup a proxy to get around your problem. That way the Tomcat server will appear to be sourcing the files while actually just passing them on from somewhere else.
Dan Josephs
Greenhorn

Joined: Jun 25, 2012
Posts: 4
Tim,
Thanks again for your help. Much appreciated!
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Tomcat - Domain Authentication
 
Similar Threads
How to secure my page
how to access other folders outside webapp in tomcat6
IIS Integrated Authentication + Tomcat Form-based (or basic) Authentication
BASIC authenication
JBoss-Tomcat and UsersRolesLoginModule