IIS, Tomcat, JNDI and ActiveDirectory
Hi,
i've got a Microsoft IIS 6.0 Webservice.
Behind the IIS is an Apache Tomcat 5.5.26 (connected via ISAPI and
AJP/1.3) protocoll.
In the IIS Integrated Windows Authentication is enabled.
On server.xml tomcatauthentication is set to false.
Also o've configured a JNDI REALM:
Realm className=org.apache.catalina.realm.JNDIRealm debug=99
connectionURL=ldap://:389/;
connectionName=*
connectionPassword=*
userBase=OU=**,OU=,OU=**,DC=**,DC=
userSearch=(sAMAccountName={0})
userSubtree=true
userRoleName=memberOf
roleBase=OU=**,OU=**,OU=**,OU=**,OU=*,DC=*,
DC=*
roleName=name
roleSubtree=true
roleSearch=(cn={0})
/
in the web.xml of Tomcat (/conf/web.xml) i've configured an
security-constraint:
security-constraint
web-resource-collection
web-resource-nameTest/web-resource-name
url-pattern/*/url-pattern
http-methodGET/http-method
http-methodPOST/http-method
http-methodPUT/http-method
http-methodDELETE/http-method
/web-resource-collection
auth-constraint
role-namesome_ad_role_name/role-name
/auth-constraint
/security-constraint
security-role
descriptionOnly 'tomcat' role is allowed to access this web
application/description
role-namesome_ad_role_name/role-name
/security-role
Now,
i'ld like to realize, that Tomcat give access only to users,
which are in one Active Directory Group detected on IIS.
Can anybody help me?
Thanks in advice
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: IIS, Tomcat, JNDI and ActiveDirectory
Hi Joerg.
The following remarks are more a question from me, than an answer to
you. I am interested also in a real answer from someone who really knows..
Buchner, Joerg [T0I] (VW Sachsen) wrote:
Hi,
i've got a Microsoft IIS 6.0 Webservice.
Behind the IIS is an Apache Tomcat 5.5.26 (connected via ISAPI and
AJP/1.3) protocoll.
In the IIS Integrated Windows Authentication is enabled.
Ok, so IIS authenticates the user's browser session, and gets a Windows
Domain user-id.
Then the AJP protocol passes this user-id to Tomcat (presumably as a
request attribute).
On server.xml tomcatauthentication is set to false.
Allright, so Tomcat believes the user-id as it is given by AJP, and
sets this in its own internal UserPrincipal structure.
Also o've configured a JNDI REALM:
Realm className=org.apache.catalina.realm.JNDIRealm debug=99
connectionURL=ldap://:389/;
connectionName=*
connectionPassword=*
userBase=OU=**,OU=,OU=**,DC=**,DC=
userSearch=(sAMAccountName={0})
userSubtree=true
userRoleName=memberOf
roleBase=OU=**,OU=**,OU=**,OU=**,OU=*,DC=*,
DC=*
roleName=name
roleSubtree=true
roleSearch=(cn={0})
/
Does the above not *interfere* with what you are trying to do, more than
it helps ?
I mean, you already have an authenticated user-id, of which you are sure
that it is in the AD directory. All that is needed now, is to get from
AD, whatever fields that contain the role-name(s) which we are looking
for, and compare with what we want to allow for this webapp.
Do the roles or groups, as understood by AD, match the roles as
understood by Tomcat ?
in the web.xml of Tomcat (/conf/web.xml) i've configured an
security-constraint:
security-constraint
web-resource-collection
web-resource-nameTest/web-resource-name
url-pattern/*/url-pattern
http-methodGET/http-method
http-methodPOST/http-method
http-methodPUT/http-method
http-methodDELETE/http-method
/web-resource-collection
auth-constraint
role-namesome_ad_role_name/role-name
/auth-constraint
/security-constraint
security-role
descriptionOnly 'tomcat' role is allowed to access this web
application/description
role-namesome_ad_role_name/role-name
/security-role
As far as I understand, with the above, Tomcat is going to issue a
HttpServletRequest.isUserInRole(some_ad_role_name) call, and only
allow access if the response is true.
Is that going to work in this case ?
It is not very clear (to me at least), what this isUserInRole() is going
to refer to.
Now,
i'ld like to realize, that Tomcat give access only to users,
which are in one Active Directory Group detected on IIS.
Since you already receive an authenticated user-id from IIS (but only a
user-id), I would do the rest with a servlet filter wrapping your
application (and allowing access or not depending on what it finds in AD
for this user), rather than with the standard Tomcat declarative
security model.
But maybe that's only my own ignorance speaking.
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
AW: IIS, Tomcat, JNDI and ActiveDirectory
Hi André
yes, you alright.
With the Integrated Windows Authentication Tomcat gets only authenticated AD
Users.
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.
That is my problem.
I found an article on internet, that this is a feature from the ISAPI
Redirector.
So, users can call JSP Sites directly without authorisation,
but we have not authorisation modules in the application.
That is my problem.
So, i'll secure the whole tomcat,
that tomcat check the permission of the user in an ActiveDirectory Group?
Thank you in advise.
Joerg
-Ursprüngliche Nachricht-
Von: André Warnier [mailto:a...@ice-sa.com]
Gesendet: Dienstag, 29. September 2009 17:45
An: Tomcat Users List
Betreff: Re: IIS, Tomcat, JNDI and ActiveDirectory
Hi Joerg.
The following remarks are more a question from me, than an answer to
you. I am interested also in a real answer from someone who really knows..
Buchner, Joerg [T0I] (VW Sachsen) wrote:
Hi,
i've got a Microsoft IIS 6.0 Webservice.
Behind the IIS is an Apache Tomcat 5.5.26 (connected via ISAPI and
AJP/1.3) protocoll.
In the IIS Integrated Windows Authentication is enabled.
Ok, so IIS authenticates the user's browser session, and gets a Windows
Domain user-id.
Then the AJP protocol passes this user-id to Tomcat (presumably as a
request attribute).
On server.xml tomcatauthentication is set to false.
Allright, so Tomcat believes the user-id as it is given by AJP, and
sets this in its own internal UserPrincipal structure.
Also o've configured a JNDI REALM:
Realm className=org.apache.catalina.realm.JNDIRealm debug=99
connectionURL=ldap://:389/;
connectionName=*
connectionPassword=*
userBase=OU=**,OU=,OU=**,DC=**,DC=
userSearch=(sAMAccountName={0})
userSubtree=true
userRoleName=memberOf
roleBase=OU=**,OU=**,OU=**,OU=**,OU=*,DC=*,
DC=*
roleName=name
roleSubtree=true
roleSearch=(cn={0})
/
Does the above not *interfere* with what you are trying to do, more than
it helps ?
I mean, you already have an authenticated user-id, of which you are sure
that it is in the AD directory. All that is needed now, is to get from
AD, whatever fields that contain the role-name(s) which we are looking
for, and compare with what we want to allow for this webapp.
Do the roles or groups, as understood by AD, match the roles as
understood by Tomcat ?
in the web.xml of Tomcat (/conf/web.xml) i've configured an
security-constraint:
security-constraint
web-resource-collection
web-resource-nameTest/web-resource-name
url-pattern/*/url-pattern
http-methodGET/http-method
http-methodPOST/http-method
http-methodPUT/http-method
http-methodDELETE/http-method
/web-resource-collection
auth-constraint
role-namesome_ad_role_name/role-name
/auth-constraint
/security-constraint
security-role
descriptionOnly 'tomcat' role is allowed to access this web
application/description
role-namesome_ad_role_name/role-name
/security-role
As far as I understand, with the above, Tomcat is going to issue a
HttpServletRequest.isUserInRole(some_ad_role_name) call, and only
allow access if the response is true.
Is that going to work in this case ?
It is not very clear (to me at least), what this isUserInRole() is going
to refer to.
Now,
i'ld like to realize, that Tomcat give access only to users,
which are in one Active Directory Group detected on IIS.
Since you already receive an authenticated user-id from IIS (but only a
user-id), I would do the rest with a servlet filter wrapping your
application (and allowing access or not depending on what it finds in AD
for this user), rather than with the standard Tomcat declarative
security model.
But maybe that's only my own ignorance speaking.
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: IIS, Tomcat, JNDI and ActiveDirectory
2009/9/29 Buchner, Joerg [T0I] (VW Sachsen) joerg.buch...@volkswagen.de: 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. The NTFS permissions work just fine for JSP files, as they work for all files. However, Tomcat and IIS have different security models, so just fine doesn't do what you might expect :-). IIS is a native Windows application, so each thread can impersonate a user. This means that when the thread tries to open a file, the permissions that are tested are the permissions of the user that's being impersonated. Tomcat is a Java application, and has no notion of threads impersonating users - each thread runs as the same user that Tomcat starts as. This means that when the thread tries to open a file, the permissions that are tested are the permissions of the user that Tomcat started as. This is not a feature of the ISAPI redirector. It's a core part of any Java application - threads in Java apps cannot impersonate users. You *might* be able to get round it with some nasty JNI code that got hold of the Windows thread correspondingto the Java thread and set the impersonation, but this would be very messy to get right - particularly making sure the impersonation is reset correctly in all error cases. This means that your approach is the correct one. You'll have to do the test in your own code somehow, and obtaining the identity of the user then checking against (a cache of) the AD group memberships seems like a good way to go. Do make sure you cache it, as repeated LDAP lookups will be slow! - Peter - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
AW: IIS, Tomcat, JNDI and ActiveDirectory
Hi Peter, thank you very much for this very helpful information. Is it now possible, that tomcat checks via JNDI an ActiveDirctory GroupMembership of the detected User (e.g. SAMPLEPC\User1) I'ld try to configure, that my users do not have an login prompt in browser Thank you in advice -Ursprüngliche Nachricht- Von: peter.crowth...@googlemail.com [mailto:peter.crowth...@googlemail.com] Im Auftrag von Peter Crowther Gesendet: Dienstag, 29. September 2009 18:28 An: Tomcat Users List Betreff: Re: IIS, Tomcat, JNDI and ActiveDirectory 2009/9/29 Buchner, Joerg [T0I] (VW Sachsen) joerg.buch...@volkswagen.de: 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. The NTFS permissions work just fine for JSP files, as they work for all files. However, Tomcat and IIS have different security models, so just fine doesn't do what you might expect :-). IIS is a native Windows application, so each thread can impersonate a user. This means that when the thread tries to open a file, the permissions that are tested are the permissions of the user that's being impersonated. Tomcat is a Java application, and has no notion of threads impersonating users - each thread runs as the same user that Tomcat starts as. This means that when the thread tries to open a file, the permissions that are tested are the permissions of the user that Tomcat started as. This is not a feature of the ISAPI redirector. It's a core part of any Java application - threads in Java apps cannot impersonate users. You *might* be able to get round it with some nasty JNI code that got hold of the Windows thread correspondingto the Java thread and set the impersonation, but this would be very messy to get right - particularly making sure the impersonation is reset correctly in all error cases. This means that your approach is the correct one. You'll have to do the test in your own code somehow, and obtaining the identity of the user then checking against (a cache of) the AD group memberships seems like a good way to go. Do make sure you cache it, as repeated LDAP lookups will be slow! - Peter - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: AW: IIS, Tomcat, JNDI and ActiveDirectory
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
