IIS connector, several connectors with different authentication to one Tomcat
Requirement: a) /myapp authenticated against AD for all users with Windows authentication b) /myapp/API authenticated against AD for /one/ user with basic-auth The plan was to have two sites in IIS with appropriate authentication schemes. They both have a 'jakarata' virtual directory pointing to one and the same physical path (DLL etc.). Then we wanted to alter the security settings on the directory excluding all but one user for requirement b). Since this modifies the security settings of the physical folder we'd have to install the IIS Tomcat connector a second time pointing to the same AJP port (one Tomcat instance). Should this work in general? Are there better alternatives to implement the given requirements? Cheers, Marcel -- Marcel Stör, http://www.frightanic.com Couchsurfing: http://www.couchsurfing.com/people/marcelstoer O ascii ribbon campaign - stop html mail - www.asciiribbon.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: IIS connector, several connectors with different authentication to one Tomcat
First, thank you so much for the thorough response. On 08.03.2012 14:47, André Warnier wrote: Marcel Stör wrote: Requirement: a) /myapp authenticated against AD for all users with Windows authentication b) /myapp/API authenticated against AD for /one/ user with basic-auth The plan was to have two sites in IIS with appropriate authentication schemes. They both have a 'jakarata' virtual directory pointing to one and the same physical path (DLL etc.). Then we wanted to alter the security settings on the directory excluding all but one user for requirement b). Since this modifies the security settings of the physical folder we'd have to install the IIS Tomcat connector a second time pointing to the same AJP port (one Tomcat instance). Should this work in general? Are there better alternatives to implement the given requirements? You are not really saying at which level you are doing this authentication (IIS or Tomcat), but I will assume you do it at the IIS level, and set tomcatAuthentication=false in the Tomcat AJP Connector. Correct. The first thing I would like to point out is that your (b) mechanism may not be applicable in some environments, as it may not be allowed by the network security policies, and the browsers may not even be /allowed/ to do Basic authentication. You should maybe check that first with the network admins. I understand that. We're in a closed environment that we don't control but understand. My second question would be why 2 sites ?. Does IIS not allow you to specify authentication requirements on a per-location base inside the same site ? I don't know (yet) - I wish the customer had allowed us to use Apache httpd. Normally, in decent webservers (like Apache httpd and Tomcat ;-)), the longest matching path wins, so for a request pointing to /myapp/API, the specification in /myapp/API should be applied, and not the one for /myapp. You should not need 2 sites, nor two connectors, for this. That'd be my preference, too. You have also not really explained why you want to do Basic auth for /myapp/API. I suspect that it is because this URL would be accessed by some client other than a browser, and this client is not able to do NTLM auth. It may help to confirm this. Correct. In a spirit of widening your scope of investigation, you may also want to have a look at having your client access Tomcat's /myapp/API directly (bypassing IIS), and in that case do the AD authentication at the Tomcat level, using Tomcat's SPNEGO authentication Valve, or Waffle or Jespa (commercial). Jespa for instance provides ample possibilities to try NTLM/SPNEGO first, and if it doesn't work fall back to Basic auth (still with an AD back-end). This scheme would even work via IIS and AJP, if you tell IIS to not authenticate for /myapp/API and proxy the call to Tomcat anyway, letting Tomcat do the authentication. We only brought IIS into the game because it felt like the easiest option to get NTLM/SPNEGO done. I'm aware of the alternatives but have never used either of them (in contrast to IIS). In summary, there are probably several ways to do this, depending on your exact circumstances/requirements. The more details you provide though, the better people on this list may be able to help you. Hope the above clarifications help. Cheers, Marcel -- Marcel Stör, http://www.frightanic.com Couchsurfing: http://www.couchsurfing.com/people/marcelstoer O ascii ribbon campaign - stop html mail - www.asciiribbon.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: IIS connector, several connectors with different authentication to one Tomcat
On 08.03.2012 15:39, André Warnier wrote: Additional notes in the text below. Marcel Stör wrote: First, thank you so much for the thorough response. On 08.03.2012 14:47, André Warnier wrote: Marcel Stör wrote: Requirement: a) /myapp authenticated against AD for all users with Windows authentication b) /myapp/API authenticated against AD for /one/ user with basic-auth The plan was to have two sites in IIS with appropriate authentication schemes. They both have a 'jakarata' virtual directory pointing to one and the same physical path (DLL etc.). Then we wanted to alter the security settings on the directory excluding all but one user for requirement b). Since this modifies the security settings of the physical folder This is something I do not understand really. You are talking about a location /myapp/API in the URL space, which is in effect proxied to Tomcat. So there should be no need for a physical disk location for /myapp or /myapp/API, nor permissions for it at the directory level. Or is this some other quirk of IIS ? Sorry if I confused you (I have to be careful I don't confuse myself, too). /myapp is the context root of the application as deployed in Tomcat. 'jakarta' is the virtual directory in IIS that points to c:/iis-tomcat-connector. The connector is configured so that /* is mapped to the one and only worker. The :80 IIS site has one permission scheme: internal Windows authentication. - the application is available at :80 over NTLM/SPNEGO The requirement was to offer the application's SOAP API at /myapp/API with basic-auth for one single user. First we set up a second IIS site at :81 only offers the basic-auth authentication scheme. This site also has a virtual directory 'jakarta' that points the the same physical path as the 'jakarta' virtual directory in the :80 site. - the application is available at :81 over basic-auth I have no idea whether this is a feasible approach at all since we're all pretty knew to IIS and the Tomcat connector. The catch: basic-auth works but there seems to be no way we can restrict that channel to a single user. If you modify the permissions of the respective 'jakarta' virtual directory in IIS what you effectively modify are the security settings of the physical folder 'jakarta' points to. That's why we wondered whether setting up a second physical folder with the connector would solve this. However, it all seems like a terrible quirk and I have a feeling we hit a dead end. (I have also occasionally worked with IIS for authentication and proxying, but I'm no great specialist in it; but I would assume that it is possible to define this as some kind of virtual location or something, without having to create a real directory on the IIS host). we'd have to install the IIS Tomcat connector a second time pointing to the same AJP port (one Tomcat instance). Should this work in general? Are there better alternatives to implement the given requirements? You are not really saying at which level you are doing this authentication (IIS or Tomcat), but I will assume you do it at the IIS level, and set tomcatAuthentication=false in the Tomcat AJP Connector. Correct The first thing I would like to point out is that your (b) mechanism may not be applicable in some environments, as it may not be allowed by the network security policies, and the browsers may not even be /allowed/ to do Basic authentication. You should maybe check that first with the network admins. I understand that. We're in a closed environment that we don't control but understand. My second question would be why 2 sites ?. Does IIS not allow you to specify authentication requirements on a per-location base inside the same site ? I don't know (yet) - I wish the customer had allowed us to use Apache httpd. Do you have any other need for the front-end IIS, other than this authentication ? No, not really. Could your client program access the Tomcat host directly ? Yeah, we might be able to convince our customer that this be the best option. Normally, in decent webservers (like Apache httpd and Tomcat ;-)), the longest matching path wins, so for a request pointing to /myapp/API, the specification in /myapp/API should be applied, and not the one for /myapp. You should not need 2 sites, nor two connectors, for this. That'd be my preference, too. You have also not really explained why you want to do Basic auth for /myapp/API. I suspect that it is because this URL would be accessed by some client other than a browser, and this client is not able to do NTLM auth. It may help to confirm this. Correct. So what is the client exactly, and where is it running (from a network/Domain point of view) ? It may matter for the best solution. There are several SOAP clients implemented in either Java or some .NET language. They are deployed in different zones in the customer's infrastructure. We need to assume that they don't support the NTLM/SPNEGO
Logging issue in Eclipse/WTP (disable request logging)
It seems nowadays you need a PHD just to understand Tomcat logging...sigh. In one of my Eclipse/WTP projects Tomcat logs each request (before and after): ... 13.02.2012 20:50:47 org.apache.catalina.core.ApplicationContext log INFO: After request [uri=/demo-webmvc-web/scripts/libs/jquery/jquery-1.6.4.min.js?null] 13.02.2012 20:50:47 org.apache.catalina.core.ApplicationContext log INFO: Before request [uri=/demo-webmvc-web/images/logo.gif?null] 13.02.2012 20:50:47 org.apache.catalina.core.ApplicationContext log INFO: After request [uri=/demo-webmvc-web/images/logo.gif?null] ... How do I get rid of this? Cheers, Marcel -- Marcel Stör, http://www.frightanic.com Couchsurfing: http://www.couchsurfing.com/people/marcelstoer O ascii ribbon campaign - stop html mail - www.asciiribbon.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Logging issue in Eclipse/WTP (disable request logging)
On 14.02.2012 22:57, Christopher Schultz wrote: In one of my Eclipse/WTP projects Tomcat logs each request (before and after): ... 13.02.2012 20:50:47 org.apache.catalina.core.ApplicationContext log INFO: After request [uri=/demo-webmvc-web/scripts/libs/jquery/jquery-1.6.4.min.js?null] 13.02.2012 20:50:47 org.apache.catalina.core.ApplicationContext log INFO: Before request [uri=/demo-webmvc-web/images/logo.gif?null] 13.02.2012 20:50:47 org.apache.catalina.core.ApplicationContext log INFO: After request [uri=/demo-webmvc-web/images/logo.gif?null] ... How do I get rid of this? That depends. In what log file does this appear? What version of Tomcat are you using? I see those statements in the Eclipse console (sys error) and I'm using Tomcat 7.0.19. Sorry, this was crucial information I forget to provide. Marcel -- Marcel Stör, http://www.frightanic.com Couchsurfing: http://www.couchsurfing.com/people/marcelstoer O ascii ribbon campaign - stop html mail - www.asciiribbon.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat connector for IIS, are user groups passed along?
On 12.10.2011 22:47, André Warnier wrote: Marcel Stör wrote: Scenario: use Integrated Windows Security (Kerberos/NTLM) for the site in IIS that delegates to Tomcat. Question: would the ISAPI connector be able to pass the Active Directory groups (i.e. user's membership info) along to Tomcat in the request? I am not the ultimate expert on this, but awaiting the ultimate expert's confirmation, I would say : How would I be able to identify the mysterious ultimate expert should he appear here ;-) - it does not do it right now - it would probably require serious coding changes to do it (notably because in the AJP protocol, there is no attribute or packet type foreseen to pass such information per se) - and there are some conceptual issues linked to this, essentially because the very notion of AD/NTLM user groups is something valid only in an MS-centric context (and Tomcat has to work in other contexts). (*) Question 2: if yes, could I call request.isUserInRole(roleName) in the Tomcat app? If you mean to say that you would use the name of an NTLM group as roleName above, that'a a different matter, and also with some conceptual difficulties. The notions of roles in Tomcat, and the notion of user groups are somewhat different. This being said, there is one (commercial but affordable) product which allows you to do something of the kind. Have a look at Jespa (www.ioplex.com). Download the product (free), and read the User's Guide that comes with it, particularly what it has to say about user groups and roles. This product works purely at the Tomcat level, as an authenticating servlet filter. So it does not use the authentication already made by IIS, it does it all at the Tomcat level. This may of may not suit your needs, but if your ultimate purpose is to have a Windows Domain kind of authentication and SSO, and allow/deny access to applications based on user Domain group membership, then it can do that. For another option, in Tomcat 7.x there is also a new SPNEGO authentication mechanism available, described here : http://tomcat.apache.org/tomcat-7.0-doc/config/valve.html#SPNEGO_Valve I really do not know much about it, as I use the Jespa mentioned above. Maybe someone else can opine if this Valve provides access to the user's NTLM groups ? (*) Also, but probably a very long shot : some recent discussion on this list, prompted by someone having difficulties with large headers being passed to Tomcat via AJP, seemed to indicate that the NTLM Authorization headers which are sent by the (authenticated) browser to Tomcat (via IIS), include the user's group membership in some form. This is probably encrypted, but it may be possible to decrypt this at the Tomcat level. Ah good, this subject popped up in a different context just a few days ago (Windows sys admin having problems with user how are in 100ds of AD groups). Do you happen to have a pointer to that discussion? Cheers, Marcel -- Marcel Stör, http://www.frightanic.com Couchsurfing: http://www.couchsurfing.com/people/marcelstoer O ascii ribbon campaign - stop html mail - www.asciiribbon.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat connector for IIS, are user groups passed along?
On 13.10.2011 00:14, chris derham wrote: - it would probably require serious coding changes to do it (notably because in the AJP protocol, there is no attribute or packet type foreseen to pass such information per se) - and there are some conceptual issues linked to this, essentially because the very notion of AD/NTLM user groups is something valid only in an MS-centric context (and Tomcat has to work in other contexts). Kerberos is cross platform standard, allowing for groups to be embedded in the token. Nothing windows specific about that. I've definitely had windows primary domain controller and clients running on Windows talking to a tomcat running on Linux, and allowing access to the group info in the kerberos tokens How did you configure this? Was Tomcat responsible for the Kerberos authentication against the Windows Active Directory? For another option, in Tomcat 7.x there is also a new SPNEGO authentication mechanism available, described here : http://tomcat.apache.org/tomcat-7.0-doc/config/valve.html#SPNEGO_Valve SPNEGO is Simple Protocol for Negotiating Authentication (or something like that). It basically causes a Kerberos token to be added via a http header called authentication. I don't know anything about the ISAPI connector, but if it could pass through the authentication header with the kerberos token, then tomcat side you can decode the kerberos token and access the users groups. So that should work, and should work at no cost - well you'll need to spend some time configuring it and getting accounts setup, but should be easy enough. Do you happen to have instructions for this? Cheers, Marcel -- Marcel Stör, http://www.frightanic.com Couchsurfing: http://www.couchsurfing.com/people/marcelstoer O ascii ribbon campaign - stop html mail - www.asciiribbon.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat connector for IIS, are user groups passed along?
On 13.10.2011 10:38, Mark Thomas wrote: On 13/10/2011 07:41, Marcel Stör wrote: On 12.10.2011 22:47, André Warnier wrote: Marcel Stör wrote: Scenario: use Integrated Windows Security (Kerberos/NTLM) for the site in IIS that delegates to Tomcat. Question: would the ISAPI connector be able to pass the Active Directory groups (i.e. user's membership info) along to Tomcat in the request? I am not the ultimate expert on this, but awaiting the ultimate expert's confirmation, I would say : How would I be able to identify the mysterious ultimate expert should he appear here ;-) Generally, a couple of different ways: - An @apache.org e-mail address is usually a good sign - A name that appears here http://tomcat.apache.org/whoweare.html For this specific question, looking at the commit log for the IIS specific part of the native code, you ideally want Rainer, Tim or Mladen for the ultimate expert although there isn't anything I would fault in André's original response. - it does not do it right now Correct. - it would probably require serious coding changes to do it (notably because in the AJP protocol, there is no attribute or packet type foreseen to pass such information per se) Agreed. - and there are some conceptual issues linked to this, essentially because the very notion of AD/NTLM user groups is something valid only in an MS-centric context (and Tomcat has to work in other contexts). Usually the mapping is group== role. Combine this with the role mapping available in web.xml and you can usually handle most situations. I can think of a couple of ways that this could be hacked together if you wanted to keep IIS in the picture. One option is to get (somehow) IIS to add the groups as an HTTP header and then use a filter on the Tomcat side to wrap the request, insert the groups into the wrapper and then use then in any call is isUserInRole(). The other is to use the built-in support for passing the user name from IIS to Tomcat and then write a filter that looks up the roles for that user from AD and then inserts them in a similar way as the previous option. Actually dropping IIS and doing the authentication and authorization directly in Tomcat is probably easier. Yeah, I'm considering this, too. Actually I guess my problem is not that I have too few options but rather too many. Context: Java web app with Spring Security (SS). a) use IIS for Windows Authentication a1) write filter to look up roles in AD a2) or use SS pre-authentication and look up roles in AD b) drop IIS b1) do authentication and authorization in Tomcat (combined with SS) b2) or use SS Kerberos extension b3) or use Waffle I've got no experience with either of these but my favorites are/were a2 and b2. (*) Question 2: if yes, could I call request.isUserInRole(roleName) in the Tomcat app? If you mean to say that you would use the name of an NTLM group as roleName above, that'a a different matter, and also with some conceptual difficulties. The notions of roles in Tomcat, and the notion of user groups are somewhat different. See previous comment. This being said, there is one (commercial but affordable) product which allows you to do something of the kind. Have a look at Jespa (www.ioplex.com). There are a couple of open source alternatives as well. See http://tomcat.apache.org/tomcat-7.0-doc/windows-auth-howto.html#Third_party_libraries For another option, in Tomcat 7.x there is also a new SPNEGO authentication mechanism available, described here : http://tomcat.apache.org/tomcat-7.0-doc/config/valve.html#SPNEGO_Valve I really do not know much about it, as I use the Jespa mentioned above. Maybe someone else can opine if this Valve provides access to the user's NTLM groups ? The SPNEGO authenticator only handles authentication but combine it with the JNDIRealm pointing to an AD instance and you'll get the roles as well. (*) Also, but probably a very long shot : some recent discussion on this list, prompted by someone having difficulties with large headers being passed to Tomcat via AJP, seemed to indicate that the NTLM Authorization headers which are sent by the (authenticated) browser to Tomcat (via IIS), include the user's group membership in some form. This is probably encrypted, but it may be possible to decrypt this at the Tomcat level. Ah good, this subject popped up in a different context just a few days ago (Windows sys admin having problems with user how are in 100ds of AD groups). Do you happen to have a pointer to that discussion? I think this is what you want: http://tomcat.markmail.org/thread/qbj376riu2rclt3n Thanks for the link, very helpful Cheers, Marcel -- Marcel Stör, http://www.frightanic.com Couchsurfing: http://www.couchsurfing.com/people/marcelstoer O ascii ribbon campaign - stop html mail - www.asciiribbon.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
Tomcat connector for IIS, are user groups passed along?
Scenario: use Integrated Windows Security (Kerberos/NTLM) for the site in IIS that delegates to Tomcat. Question: would the ISAPI connector be able to pass the Active Directory groups (i.e. user's membership info) along to Tomcat in the request? Question 2: if yes, could I call request.isUserInRole(roleName) in the Tomcat app? Cheers, Marcel -- Marcel Stör, http://www.frightanic.com Couchsurfing: http://www.couchsurfing.com/people/marcelstoer O ascii ribbon campaign - stop html mail - www.asciiribbon.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Static resources not found in embedded Tomcat
On 01.05.2009, at 10:20, Mark Thomas wrote: Marcel Stör wrote: All I need for an embedded Tomcat (I'm working with 6.x) are a few Tomcat JARs in my classpath, correct? It depends what functionality you want - you'll probably need most of them. I'm asking because I'm seeing a strange behavior here. Access to Servlets deployed in the embedded Tomcat succeed, but requests to other resources such as JSPs or static CSS files result in 404 errors. I have a feeling that I'm missing something in my Tomcat setup. Here's my Tomcat launcher class: That sounds like you haven't configured the JSP servlet or the default servlet. Take a look at CATALINA_BASE/conf/web.xml - you probably want to include some of that stuff in your app's web.xml Oh yes, indeed. Isn't it obvious...gosh. Regards, Marcel -- Marcel Stör, http://www.frightanic.com Blog: http://frightanic.wordpress.com Couchsurfing: http://www.couchsurfing.com/people/marcelstoer Skype: marcelstoer - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Static resources not found in embedded Tomcat
All I need for an embedded Tomcat (I'm working with 6.x) are a few
Tomcat JARs in my classpath, correct?
I'm asking because I'm seeing a strange behavior here. Access to
Servlets deployed in the embedded Tomcat succeed, but requests to
other resources such as JSPs or static CSS files result in 404 errors.
I have a feeling that I'm missing something in my Tomcat setup. Here's
my Tomcat launcher class:
public class EmbeddedTomcat {
private String context = null;
private String docBase;
private int port;
private Embedded container = null;
private Log logger = LogFactory.getLog(getClass());
/**
* Creates a single-webapp configuration to be run in Tomcat.
* * @param contextRoot without leading slash, e.g. mywebapp
* @param docBase the web resources directory for the web application
i.e. the
* absolute (or relative) path to the content to be served under
mywebapp
* @param port the port
*/
public EmbeddedTomcat(String contextRoot, String docBase, int port) {
assert !contextRoot.startsWith(/);
this.context = / + contextRoot;
this.docBase = docBase;
this.port = port;
setupContainer();
}
private void setupContainer() {
// create server
container = new Embedded();
container.setCatalinaHome(findTomcatHome());
// create webapp loader
WebappLoader loader = new
WebappLoader(this.getClass().getClassLoader());
// create context
Context rootContext = container.createContext(context, docBase);
rootContext.setLoader(loader);
rootContext.setReloadable(true);
// create host
Host localHost = container.createHost(localHost, new
File().getAbsolutePath());
// one could call addChild for each web app...
localHost.addChild(rootContext);
// create engine
Engine engine = container.createEngine();
engine.setName(localEngine);
engine.addChild(localHost);
engine.setDefaultHost(localHost.getName());
container.addEngine(engine);
// create http connector
Connector httpConnector = container.createConnector((InetAddress)
null, port, false);
container.addConnector(httpConnector);
container.setAwait(true);
}
/**
* Tomcat will create its work directory in this folder! Hence, the
process
* must have write access to it. To make this portable the system
property
* java.io.tmpdir is suffixed with embedded-tomcat.
*/
private String findTomcatHome() {
String path;
try {
path = new File(System.getProperty(java.io.tmpdir), embedded-
tomcat).getCanonicalPath();
} catch (IOException e) {
path = embedded-tomcat;
}
return path;
}
/**
* Starts the embedded Tomcat server.
* * @throws LifecycleException if the server could not be started
*/
public void start() throws LifecycleException {
// starts server
container.start();
// add shutdown hook to stop server
Runtime.getRuntime().addShutdownHook(new Thread() {
public void run() {
EmbeddedTomcat.this.stop();
}
});
}
/**
* Stops the embedded Tomcat server.
*/
public void stop() {
try {
if (container != null) {
container.stop();
}
} catch (LifecycleException exception) {
logger.warn(Cannot Stop Tomcat + exception.getMessage());
}
}
public String getContext() {
return context;
}
public int getPort() {
return port;
}
}
That's how I start it:
EmbeddedTomcat tomcat = new EmbeddedTomcat(myapp, C:/
my_unpacked_war, );
tomcat.start();
C:/my_unpacked_war contains
/WEB-INF/web.xml
/WEB-INF/classes/...
/css/style.css
/index.jsp
Requests to localhost:/myapp/index.jsp result in 404 and so does
localhost:/myapp/css/style.css. However if I access the Servlets
directly with the URLs they're mapped under everything works fine.
Kind regards,
Marcel
--
Marcel Stör, http://www.frightanic.com
Blog: http://frightanic.wordpress.com
Couchsurfing: http://www.couchsurfing.com/people/marcelstoer
Skype: marcelstoer
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Request not forwarded to login page with security-constraint after session time-out
On 27.02.2009, at 17:38, Christopher Schultz wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Chuck, On 2/26/2009 5:39 PM, Caldarale, Charles R wrote: From: Mark Thomas [mailto:ma...@apache.org] Subject: Re: Request not forwarded to login page with security-constraint after session time-out The spec is clearer than that. The * role == all roles defined in web.xml. Yes, but what it's not clear about is what happens when there are *no* roles defined in web.xml, which is the situation the OP has. It's worse than that: he has no roles table defined, so he gets SQLExceptions during authorization. [OT] Yes, indeed. I had expected that Tomcat would handle this more gracefully. I find it odd that JDBCRealm does try to run a query against the role table without checking first if one has even been defined. This is particularly annoying because the Realm tag in context.xml cannot be validated against a DTD or schema - from a configuration point of view I'm not required to define it. Regards, Marcel -- Marcel Stör, http://www.frightanic.com Blog: http://frightanic.wordpress.com Couchsurfing: http://www.couchsurfing.com/people/marcelstoer Skype: marcelstoer - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Request not forwarded to login page with security-constraint after session time-out
Gregor Schneider wrote: Marcel, On Thu, Feb 26, 2009 at 12:16 AM, Marcel Stör mar...@frightanic.com wrote: [Problem] Upon session time-out the request is not forwarded to the login page (form based auth). Nothing happens on the UI. However, forwarding to the login page does work during the initially login into the application. Not sure if I get you right: Do you expect an *automatic* forwarding to the login-page? Or are your requesting a protected url *after* session has timed out? Well, a bit of both ;-) If I request a protected URL (manually clicking link, AJAX request, etc.) *after* the session has timed out I expect an automatic forwarding to the login page. As I could see while debugging, the request dispatcher does indeed issue a forward() to the login page but nothing happens. If the latter: In the Tomcat-access-logs, do you seen any HTTP 40x? I need to check. PS.: This looks a bit awkward to me (didn't know that this is possible), but I guess that's not the reason for your problem: role-name*/role-name I'm sure either, I saw it in some tutorial. Since I don't have a role table (right, JDBCRealm complains about that, but whatever...) it basically means that I don't use role based access. PPS: Compliments for the excellent problem-decription! Thanks, after all I need people to help me. So, it's in my own best interest. Marcel -- Marcel Stör, http://www.frightanic.com Blog: http://frightanic.wordpress.com Couchsurfing: http://www.couchsurfing.com/people/marcelstoer Skype: marcelstoer - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Request not forwarded to login page with security-constraint after session time-out
On 26.02.2009, at 20:13, Christopher Schultz wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Marcel, On 2/26/2009 10:21 AM, Marcel Stör wrote: If I request a protected URL (manually clicking link, AJAX request, etc.) *after* the session has timed out I expect an automatic forwarding to the login page. As I could see while debugging, the request dispatcher does indeed issue a forward() to the login page but nothing happens. Error logs? HTTP dump? Note that Tomcat 5.0 has been unsupported for quite a while. I recommend planning an upgrade SOON. I'll gather some more information... I know. It's just that Google's GWT setup for local development ships with 5.0.28 embedded. We don't use 5.0 in production, don't worry. I'm sure either, I saw it in some tutorial. Since I don't have a role table (right, JDBCRealm complains about that, but whatever...) it basically means that I don't use role based access. Technically speaking, no roles defined = no access. Practically speaking, I don't believe Tomcat forces any roles to be defined when * is the role-name required by the security-constraint. No, I only mentioned this because Tomcat throws an SQL exception because it tries to query a table called if I don't specify a role table in the realm config in context.xml Regards, Marcel -- Marcel Stör, http://www.frightanic.com Blog: http://frightanic.wordpress.com Couchsurfing: http://www.couchsurfing.com/people/marcelstoer Skype: marcelstoer - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Request not forwarded to login page with security-constraint after session time-out
On 26.02.2009, at 23:44, Mark Thomas wrote: Caldarale, Charles R wrote: From: Mark Thomas [mailto:ma...@apache.org] Subject: Re: Request not forwarded to login page with security-constraint after session time-out The spec is clearer than that. The * role == all roles defined in web.xml. Yes, but what it's not clear about is what happens when there are *no* roles defined in web.xml, which is the situation the OP has. I thought it was pretty clear. If * is all roles defined and you have no roles defined then you are basically preventing anyone from accessing that resource (subject to the weird and wonderful rules on combining security constraints). Not sure I can follow you guys on this...A few questions, my assumption is that the role-issue has nothing to do with the real problem: 1. Is the *-role issues even relevant in my context? After all, the security constraint works fine if I initially log in... 2. My requirement is indeed: allow any authenticated user, ignore roles all together. So I set auth-constraint role-name*/role-name /auth-constraint /security-constraint ... security-role role-name*/role-name /security-role in web.xml and allRolesMode=AUTH_ONLY_MODE in the JDBC realm config. Correct? Uummhh, obviously not, because there's still this error in the log, but it has no impact: Feb 27, 2009 12:06:43 AM org.apache.catalina.realm.JDBCRealm getRoles SEVERE: Exception performing authentication java.sql.SQLException: ORA-00903: invalid table name at oracle.jdbc.driver.DatabaseError.throwSqlException(DatabaseError.java: 112) at oracle.jdbc.driver.T4CTTIoer.processError(T4CTTIoer.java:331) at oracle.jdbc.driver.T4CTTIoer.processError(T4CTTIoer.java:288) 3. Why does it seem to be relevant that the request where auto- forwarding-to-login-after-session-timeout fails is an AJAX request? Regards, Marcel -- Marcel Stör, http://www.frightanic.com Blog: http://frightanic.wordpress.com Couchsurfing: http://www.couchsurfing.com/people/marcelstoer Skype: marcelstoer - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Request not forwarded to login page with security-constraint after session time-out
Marcel Stör wrote: [...] 3. Why does it seem to be relevant that the request where auto-forwarding-to-login-after-session-timeout fails is an AJAX request? That was my last thought last night before I fell asleep...and my first this morning when I woke up. And then the scales fell from my eyes, it suddenly dawned on me. As expected what Tomcat does is 100% correct. The key words here are forward vs. redirect. My application sends an AJAX request to /app/AppServlet, Tomcat requires authentication because the session had timed out and dutifully *forwards* to the login page. Hence, the result of the request is not some JSON object as expected by the client in the browser but the login page HTML structure/page. The client simply isn't prepared for that and freezes. I'll go fix my application now. Sorry for the disturbance. Regards, Marcel -- Marcel Stör, http://www.frightanic.com Blog: http://frightanic.wordpress.com Couchsurfing: http://www.couchsurfing.com/people/marcelstoer Skype: marcelstoer - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Request not forwarded to login page with security-constraint after session time-out
Up to now I had always thought I understood the security aspects of the Servlet spec quite well. Looks like I was wrong... [Problem] Upon session time-out the request is not forwarded to the login page (form based auth). Nothing happens on the UI. However, forwarding to the login page does work during the initially login into the application. [Setup] Tomcat 5.0.28, but the behavior is the same in 5.5. Application entry page at /app/app.jsp. Entry Servlet at /app/AppServlet. Login page at /public/login.jsp. web.xml looks like this: security-constraint web-resource-collection web-resource-namemyapp/web-resource-name url-pattern/app/app.jsp/url-pattern http-methodGET/http-method http-methodPOST/http-method http-methodPUT/http-method http-methodDELETE/http-method /web-resource-collection web-resource-collection web-resource-namemyapp/web-resource-name url-pattern/app/AppServlet/url-pattern http-methodGET/http-method http-methodPOST/http-method http-methodPUT/http-method http-methodDELETE/http-method /web-resource-collection auth-constraint role-name*/role-name /auth-constraint /security-constraint login-config auth-methodFORM/auth-method form-login-config form-login-page/public/login.jsp/form-login-page form-error-page/public/login.jsp?retry=true/form-error-page /form-login-config /login-config security-role role-name*/role-name /security-role When I initially request /app/app.jsp Tomcat forwards to /public/ login.jsp as expected, I can login (using JDBCRealm) and will be forwarded to /app/app.jsp. [Analysis] I started Tomcat in debug mode with debug log level and set a breakpoint in FormAuthenticator.authenticate(HttpRequest, HttpResponse, LoginConfig). I see that eventually RequestDispatcher#forward() is invoked because it was detected that the request needs to be authenticated. I followed the control flow to ApplicationDispatcher.doForward(ServletRequest, ServletResponse) but nothing seems to be wrong - at least to me. The log contains the following: 23:27:55,251 DEBUG AuthenticatorBase:413 - [] Security checking request POST /app/AppServlet 23:27:55,252 DEBUG RealmBase:422 - [] Checking constraint 'SecurityConstraint[myapp, myapp]' against POST /app/AppServlet -- true 23:27:55,253 DEBUG AuthenticatorBase:484 - Calling hasUserDataPermission() 23:27:55,253 DEBUG RealmBase:752 - User data constraint has no restrictions 23:27:55,254 DEBUG AuthenticatorBase:502 - Calling authenticate() 23:28:25,246 DEBUG FormAuthenticator:208 - Save request in session '2E77E8D1AF28AA5369AE8DCD334960C5' // Why would the servletPath be empyt? Potential problem? 23:28:27,500 DEBUG ApplicationDispatcher:148 - servletPath=, pathInfo=/ public/login.jsp, queryString=null, name=null 23:29:11,136 DEBUG ApplicationDispatcher:381 - Path Based Forward 23:30:58,381 DEBUG ApplicationDispatcher:418 - Disabling the response for futher output 23:31:35,471 DEBUG AuthenticatorBase:506 - Failed authenticate() test Kind regards, Marcel -- Marcel Stör, http://www.frightanic.com Blog: http://frightanic.wordpress.com Couchsurfing: http://www.couchsurfing.com/people/marcelstoer Skype: marcelstoer - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
