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-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
