Andrew, I don't understand exactly what's entailed here, but I believe you do and when you suggest it is a better option, I'm willing to accept that. My only question, as always, focuses on backward compatibility. Will either of these options require API changes and if so, to what modules?
Terry On Wed, 2008-01-30 at 13:10 -0500, Andrew Jaquith wrote: > Hi everyone, > > I'd like to post a few quick thoughts about authentication strategies > for JSPWiki 3.0. When I say "authentication," I mean the process by > which a user logs into JSPWiki. I don't mean "authorization" -- what a > user can do once they log in. > > Since 2.4, we've used a captive JAAS (the Java Authentication and > Authorization Service) to log in users. That means we tell the JVM > where to find our login configuration, and then we execute the "login > stack" as its configured. "Authentication" via JAAS happens twice: > once when the user's HTTP request is received (so that we can grab any > container-managed credentials) and (optionally) a second time if we > authenticate against JSPWiki's user database, using Login.jsp. It's a > "captive" JAAS system in the sense that we wire it up and execute it > independently from the container. > > I suppose the details of exactly what we do don't matter nearly as > much as the technologies. In both cases, we're relying on JAAS to look > up a LoginConfiguration and execute it. > > Of course, the current strategy causes problems because it means > sometimes we need to wire up certain containers in special ways (e.g., > JBoss). And it's sometimes a deployment hassle. From the deployer > standpoint, it's probably not very obvious what the jspwiki.jaas > config file we use does. > > On the plus side, using standard JAAS LoginModules for authentication > is a good thing because it's a fairly well-defined interface, and if > developers want to plug in their own LoginModules, it's just a matter > of configuring the JAAS login config file and putting the custom > module on the classpath. So that's good. Also, we get to say that > we're doing things in a "Java standard" way. > > But I confess I've been re-thinking the authentication strategy > lately, largely because of some of the deployment hassles people have > experienced. To solve them properly, there's really only two ways to go: > > 1) Build a "clean-room" implementation of LoginContext that would re- > implement the JAAS login stack, but do it in a way that could be > instantiated per-webapp, rather than JVM-wide. That would allow us to > re-use all of our LoginModules and the JAAS config file, and is the > least invasive alternative. Precedent for this approach exists. This > is totally analogous to how we've handled the security policy > configuration issues with jspwiki.policy: the "local security policy" > scheme is, in essence, a clean-room (and portable) re-write of the > Java security Policy class. It doesn't require any special JVM config > to work, and it's the policy files it reads are line-for-line > compatible with the standard J2SE policy files. > > It's a neat approach, but not the only one. Which brings me to the > second approach: > > 2) Get rid of significant chunks of the JAAS login scheme we use, and > do something a little simpler. I'm thinking, in particular, of putting > in a very lightweight servlet filter that wraps the incoming > HttpServletRequest. It would delegate to WikiSession for > getUserPrincipal() and getRemoteUser(), and delegate to WikiSession > and AuthorizationManager for isUserInRole(). This is similar to how, > for example, ACEGI does things. For configuring custom authentication, > we'd simply put in a single line that points to ONE LoginModule to > execute. As it happens, that's what we do today in the "jswiki-custom" > configuration -- the config says, "execute [just] the > UserDatabaseLoginModule." Today, we specify the > UserDatabaseLoginModule class name in jspwiki.jaas -- all we'd be > doing is moving it to jspwiki.properties. > > I'm strongly leaning towards number 2. Benefits would include: > > - No more fooling around with the java.security.auth.login.config > system property (meaning: no more container dependencies) > - We'd throw away jspwiki.jaas > - isUserInRole() would become a lot more useful to JSPs because > callers could inquire about JSPWiki roles, and even about wiki group > membership > - "Probably" better compatibility with schemes like ACEGI > - We could slightly reduce the security privileges JSPWiki requires to > run under a security manager (hypothetically) > > Here's what wouldn't change: > > - We'd keep the JAAS UserDatabaseLoginModule class for custom > authentication (and allow it to be swapped out in favor of any > LoginModule, by changing a line in jspwiki.properties) > - We'd keep the cookie authentication technique (as much as it pains > me to do so) and the cookie-sniffing technique for "asserted" names > - WikiSession, with its embedded Subject and Principals, would still > exist and be associated with the HttpSession > - Public API for WikiSession, SessionMonitor, etc. wouldn't change > - Java security policies (and the related APIs in > AuthorizationManager) would stay exactly the same > > I don't see too many downsides to this, frankly. Really, this is more > about the "plumbing" than stuff that would be visible to users, > deployers or developers not named Andrew. > > Thoughts? There's nothing that says we need to wait until 3.0. If > everyone likes this idea, we could do it in 2.8. > > Andrew
