I've read the docs and I think I understand the basic setup of the valve to implement SSO. However, my application is only partially done and before I implement SSO, I'd like to know that when I get the application all done, it will hang together. So, I will describe what I'm doing and hopefully, someone can tell me if it all makes sense.
On a single Windows server running Tomcat 5.5.16, I will have 4 web applications (i.e., 4 Contexts). I'm using a DataSourceRealm tied to a standard JDBC Resource database for authentication. As I understand it, I need to setup the SSO valve in my <Host> along with the DataSourceRealm. Here's the architecture I currently have planned with the 4 applications (Contexts). AppA is a pretty vanilla web app with form authentication. AppB is a context that has a few image files which don't need protection and so I don't intend to have a WEB-INF directory (and consequently, no web.xml and no authentication). AppC is really a bunch of static files which get referred to from AppA html pages. I do want to protect these files. AppC will have a security-constraint which requires that the user has authenticated and has the appropriate role from AppA before they can access anything in AppC. AppC won't provide an ability to authenticate, but a user wouldn't normally access AppC directly anyway. For a number of technical reasons, putting the files from AppC in AppA's directory structure isn't a good option. AppD will be a web app with basic authentication. If the user has authenticated with AppA, I'm fine if they access AppD. However, access to AppD is normally a single round-trip (i.e., they send in a request and get a response and they're done). They are likely running an application that will do the authentication for them (hence the basic authentication) as part of a single http request (think of it as a soap request). Authenticating with AppD will use the same login/password (same DataSourceRealm) as AppA. Does that sound like something that should work with SSO? My other question is what to do with the standard Tomcat manager (which I'd like to run). It sounds like I have several choices. 1) I can set up another host and park it there. That means I have to have my DNS resolve another name to the server. 2) I could set up a Request Filter valve in the manager context and limit access based on where the request came from. I assume this also means I need to set up the appropriate login and roles in my database since the manager will now use that instead of the standard xml user file. 3) Can I move the UserDatabaseRealm into the manager context file? Will that override the Realm in the host and also keep it out of the SSO valve. Didn't sound like a promising idea, but wondered if anyone had tried that. My initial reaction is that 2) is probably the best choice of the 3 (is there another option?). Comments or suggestions? Am I on the right track? Scott
