tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From André Warnier ...@ice-sa.com>
Subject Re: AW: IIS, Tomcat, JNDI and ActiveDirectory
Date Tue, 29 Sep 2009 20:37:39 GMT
Hi Joerg.

To clear up a bit, you are talking about 2 distinct aspects : 
Authentication and Authorization.

Authentication = to find out who the user is
Authorization = when we know who the user is, determine if he has or not 
the authorization required to access some resource (in this case, some 
Tomcat webapps or JSP pages).

> With the Integrated Windows Authentication Tomcat gets only authenticated AD Users.
> 
Right.  And that solves the Authentication part : your users will not 
have to enter their login again, to access Tomcat-based applications.
Tomcat already knows who they are. (*)

Unfortunately, IIS+AJP do not pass to Tomcat the names of the Windows 
"groups" to which this user belongs.  They pass only the user-id.

> But the problem is an other:
> 
> The SourceCodes (JSP/Servlets) are secured with NTFS rights on filesystem.
> (Windows Server 2003 x64)
> I've tried to secure the whole application with NTFS Rights,
> but the NTFS ACL does not work for JSP Files.
> 

In fact, you should not look at the JSP files as files.  *Nobody* should 
have access to these files, as files, except Tomcat.  Tomcat reads these 
files, and compiles them into executable java code, and they then become 
"web applications" (in short "webapps") in memory.
(To enforce the above, you can make these JSP files belong to the local 
user-id on your Tomcat server which is used to run Tomcat, and forbid 
anyone else from accessing them (except you)).

The point is now that you want to control who can have access to the 
webapps that Tomcat creates from these pages.
That is a matter for Tomcat, and for nobody else.
Tomcat does not care about the NTFS permissions of the JSP files (as 
long as it can read them himself).  Tomcat cares only about the compiled 
webapps in memory, and who can call them.
And Tomcat cares about that from a purely Tomcat point of view, not from 
an NTFS or Windows point of view.  in fact, Tomcat has no idea of what 
an authorized Windows Domain user is, or an AD user.
Tomcat also has no idea of what an AD or Windows "group" means.
It cares only about Tomcat user-id's, and maybe "Tomcat roles" 
associated to these user-id's.

The point is, you are trying to combine two different worlds : one is 
the proprietary, single-platform world of Microsoft Windows Domain 
authentication and group membership and NTFS file permissions based on 
that; the other one is the open-source, multi-platform world of Java 
servlets and Tomcat, and access to webapps.
These worlds do not fit together perfectly, so you have to make some 
adjustments.
(Just like if you wanted to fit a Porsche engine in a Polo, you would 
have to make a special gearbox ;-)).

So your problem is that you want (entweder/oder) :

(a) to "translate" some AD/Windows attribute/group of an AD/Windows 
user-id, into something that Tomcat can understand (Tomcat roles) and 
then let Tomcat use its built-in role-based security model to allow or 
not access to the webapps.

OR

(b)(different thing), to bypass the role-based built-in security of 
Tomcat, and give access or not to the webapps, based on these AD 
attributes of the user, using some other mechanism.

For (a) above, what you have to achieve is that when Tomcat calls 
"isUserInRole(some_AD_attribute)", the response comes back as "true" or 
"false", appropriately.
Maybe there is some standard Tomcat+AD method that can be used to do 
that.  I really don't know, but maybe someone else on the list knows.

For (b), you could use a "servlet filter".  This servlet filter would 
need to take the Tomcat user-id (the same as the one obtained from IIS 
and passed to Tomcat by the AJP module and accepted by Tomcat as its 
own), build a connection to the AD system, and retrieve the "group" 
attributes of this user in AD.  Then, the servlet filter would compare 
these "groups" (as strings) to one or more strings contained in some 
filter configuration parameter (<init-param> in web.xml), and decide if 
it lets this call go through to the webapp, or not.
A "servlet filter" does not modify the application in any way.  It is a 
separate java module, and it installs "on top" of an existing 
application.  The application does not even know that it is there.

I don't know which solution between (a) and (b) above is simpler. 
Writing a servlet filter like above is not very complicated.
It may even exist already.
One issue with this, would be that you should save the result of the 
user lookup in AD (in the Tomcat session or in a cookie), to avoid 
having to do the same lookup at each new request of the same browser, 
otherwise it would be quite inefficient.

I hope this helps.


(*) there are other methods to achieve that, not depending on a 
front-end IIS, and where Tomcat obtains the user-id directly from the 
browser and the Windows DC (just like IIS does). See www.ioplex.com for 
one such solution.


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Mime
View raw message