incubator-jspwiki-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrew Jaquith <>
Subject Thoughts on authentication changes for JSPWiki 3.0
Date Wed, 30 Jan 2008 18:10:09 GMT
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

I'm strongly leaning towards number 2. Benefits would include:

- No more fooling around with the  
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  
- "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
- 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.


View raw message