Update note 18-Jul-2005:

See the new Security 2.3 page for discussion of the redesigned AAA subsystem.

General note 17-Feb-2005:

FYI: The current AAA system in the CVS version has been suspended. There will be no more development on it.

This is due to several reasons:

  • I have been unable to do any other work on any other part than the AAA system, as I always get the nagging feeling that I should really work on it.
  • I really don't like writing AAA. It's a damned complicated system which has dependencies and it touches areas that I don't just understand enough about. I also have a personal feeling that per-page permissions are NOT very useful - at least they are useful to me. They run against the Wiki philosophy, and while I understand that a bunch of people do find them useful, it's really hard to be motivated to do something you don't believe in.
  • The design of the AAA system was faulty from the get-go. This unfortunately meant that it became a bug-infested beast even before it was properly born.
  • I have little time these days, and it is frankly, better used on things that I find interesting and useful.

With all this, the development of JSPWiki has been slowed down too much. I was hoping to release 2.2 about a year ago, and I haven't been able to release even a single beta. This simply sucks. You may have noticed a flurry of updates in the recent few weeks in the CVS, and this is all due to the fact that I decided to give up on the AAA system and concentrate on the rest of the code base. I have so many ideas and things that I personally need and want that it simply does not make sense for me to keep developing a feature that is simply not interesting. (I'm planning things such as making JSPWiki Lifeblog compatible, providing proper diff and AtomAPI support, easier installation, speed optimizations, etc.)

However, all is not lost. Andrew Jaquith has promised to take over the AAA system development, and rewrite the whole thing from scratch, but it is likely not to make in the 2.2 release. If you want to help, please join the JSPWiki mailing list and engage in the discussion there.

Until then, the current AAA system in the CVS will exist, but bugs are not fixed, and no further development is done. It won't be removed, but it'll not be enabled by default.

(With that, the discussion on this page is mostly obsolete.)

-- JanneJalkanen, 17-Feb-2005

This page is a collection of observations, suggestions, and (bug) reports on JSPWiki Authentication and Authorization. It is markedly separate from BugReports and Ideas, since auth is a major development nearing its final stages; we don't want to bother the regular user/deployer with this stuff quite yet.


Killer (2003-11-03) Use Javascript to define authorization on a page?

An idea which came up on IRC: use Javascript to let the user select from a list of permissions and transfer it to the page in the valid ALLOW/DENY-format?


FrancoisParlant (2003-22-10) LeftMenu restrictions consequences

I've noticed today that if a page like LeftMenu or LeftMenuFooter contains restrictions on Edit, like:

 [{DENY edit Guest}]
[{ALLOW edit FrancoisParlant}]
This restriction will be applied to all pages, just because LeftMenu and LeftMenuFooter, are in the Edit page, and thus, even if they are not the edited page, the edit context is applied to them, which is refused by the permissions constraint.

In the example above, only people with the username authorized in LeftMenu or LeftMenuFooter can edit pages.


Add/Remove Groups hook in Authorization?#

ebu, 18-jul-2003

Should UserDatabase offer methods for creating and removing groups:

  • UserDatabase.addGroup( String group )
  • UserDatabase.removeGroup( String group )
  • UserDatabase.addMember( String group, String member )
  • UserDatabase.removeMember( String group, String member )

This capability is irrelevant for the default WikiPage-based group creation, but for any custom group lookup it is convenient. (You could always use an external tool to add records to a database, of course, but collecting the group management code in one place would keep things simpler.)

We also need to be able to call these methods in a JSP; maybe a facade call through WikiEngine?

This would be mandatory, in my opinion. It is a must for the user to be able to administer groups, at least for the Ropemylly project. --Killer


Groups don't work when using com.ecyrd.jspwiki.auth.modules.WikiDatabase#

ebu, 18-jul-2003

This is a known bootstrap problem. Replacing WikiDatabase with a custom UserDatabase class (by setting property jspwiki.userdatabase in jspwiki.properties) lets you test your own implementation while waiting for the wiki-way solution Janne's envisioned.


killer, 18-Jul-2003

Are there plans to include page owner attribute and default permissions for the owner? At the moment it is very easy to lose all permissions to a page, if the site-wide defaults are restrictive. Also it would be nice if it would be possible to propagate the permissions from the page the new page is being created from.

The propagation could be a minor addition to Edit.jsp, as long as WikiEngine (or other) provides us with a method to build the text representation of a rule. Not a bad idea. --ebu

ebu, 22-Jul-2003

Observations on auth code

To get my own testing/development on track, I had to hack around a bit. The following are changes I made to my codebase, not committed; they are listed here just in case.

  • AclImpl.java now errs on the side of caution: when findPermission() looks for matches, negatives are returned immediately, but positives are just noted and the loop continues. Unfortunately, this prevents rules of type "deny for group 'everyone'; allow for group 'someone'". (Note that the implementation does NOT prevent "deny for group 'everyone'; allow for user 'someone'", since user permissions are checked before groups. Is this what's intended?) For my purposes, I modified positives to return immediately, as well. (This should cause the order of allow/deny to be decisive. Remains to be seen what breaks, though..=)
  • UserManager.getPrincipal() is still incomplete. I modified mine to ask the UserDatabase for groups first, then check for the (internally defined) default groups, and only then return the UndefinedPrincipal the incomplete version gives by default. This change also required adding something like WikiDatabase.getGroupPrincipal(String name).
  • I am somewhat confused about the simultaneous existence of both UserManager.getPrincipal() and UserManager.getWikiGroup(). They seem to do the same thing at the moment. Some more javadoc for the former method would be useful.
    • They are actually remnants of two overlapping implementations; I changed my mind in the middle. One of these is likely to disappear.
  • Needed: concise, well defined ways of acquiring a list of valid groups, users, currently active users. (X.getAllGroupNames(), X.getUsers(), X.userExists(String userName), X.userBelongsToGroup(), X.getActiveUsers()... More detailed suggestion needs to be figured out.)
  • Something like Y.addGroup(), Y.removeGroup(), Z.addUser(), Z.removeUser() are also requested. (Yes, usually the user/group DB is either managed by external tools, or by the wiki solution - but I suspect that JSPWiki code would not be complicated much (just add the IF declarations, and empty stubs) and would help a webapp-integrated solution tremendously.) One solution is to provide a handle to the specific authentication classes, and just do a nasty cast in your custom application. Hm..

John O'Hara - 23 Sept, 2003

There are lots of ways of implementing storage for groups. I'm hoping to use my company's entrenched Domino LDAP server. This works great for authentication with Tomcat 5.0.9's JNDI LDAP authenticator. Domino can present email groups as LDAP groups, which will suit the Tomcat's definition of group membership fine. The Tomcat v5 LDAP auth mechanism is different from v4 and more useful.

It would be good if their was a groups mechanism that inherited the one being used by the servlet container too. I think Janne's Wiki Way groups will be excellent, but I'd really appreciate making the servlets idea of groups an option.

I'm currently using JSPWiki 2.0.45 - and seriously considering going to 2.1.68. ACL's are the feature I'm looking for most the the moment - followed by WebDAV :-)

Thanks, and keep up the great work.


Re-inventing the Wheel and Inventing New Security Problems#

I really think JSPWiki Authorization and Authentication is headed in the wrong direction. It should be using standard J2EE container manager security for users and roles (groups). You would be done already if you used that and you wouldn't be creating a new set of security problems to deal with. All you need to handle is the enforcement of page access rules (by getting the user and roles from the container). Containers (Tomcat, Weblogic, etc) already suppport many different authentication methods and offer the option to write you own authentication plugins. You are duplicating all that effort. Plus if I write say a custom authenticator plugin for Tomcat (or Weblogic), I would have to only write one for all apps on that container, but now I'd have to write a special one for JspWiki. And if I have several secure apps running, I lose the option for single sign-on for all apps on that server. Also, by deviating from the J2EE standard, how are you going to support portlets (single sign-on, etc)?

I'm not a J2EE expert, but would the container managed security mechanism be sufficient when all pages are named "Wiki.jsp" or "Edit.jsp", etc? I remember trying to get Tomcat at one point to challenge for a password on some pages, but it wouldn't work because Tomcat stopped looking when it saw the "?" in the URL (in other words, I couldn't set the password mechanism on a per-page -- WikiPage, that is -- basis). --MichaelGentry

you are probably confusing "declarative" security with "container managed security". You can still use container managed authentication for user/role authentication even if you aren't using declarative security for page authorization. You are correct that you cannot use standard declarative security since all the (view) pages are called "Wiki.jsp", that doesn't mean you have to use non-standard user/role authentication. Which is what I am talking about.

Simple answer: I wanted the user database to be wiki-editable as well. And actually, it should be very easy to make an adapter for J2EE container manager security, and then you can use all of the J2EE goodies. No problem. Someone just needs to do it. --JanneJalkanen

I just did it for Tomcat using JAAS. :) Adapter will be posted on a separate JAAS page -- Andrew Jaquith

OK, but you could have written a plugin for Tomcat and any other container you wanted which used a Wiki editable database and then just written page authorization using standard container managed authentication. Granted that doesn't support every container at once, but it still seems like a better solution in the long run (with portlets, et al in mind). JSPWiki is not an island. Maybe that's all you use, but it's one of several webapps that make up a total web site (portal) for me. I am pretty frustrated not just with JSPWiki, but with how so many Java web apps go off and do their own security framework. If everyone just used standard security, then I'd just drop them in the container and they'd all support my customer authenticator plugin and provide single sign on across all web apps. Instead I have to deal with each one separately and try to force them to work with the standard or write authenticator plugins for every single app. uggghhhh.
anyway, my bigger concern is that this is not possible as an adapter (I am assuming you mean WikiAuthenticator), but rather requires other changes to JSPWiki. I only glanced but looking at WikiAuthenticator, I didn't see how to get ahold of Servlet context, request and container stuff. It seems like you need an Abstract class instead of an interface so there would be something there to work with. Also, you need to be able to throw standard security exceptions so the container can ask for authentication. Unlike an authenticator plugin, you aren't taking a username and password and authenticating it but rather enforcing the container to do it. So you'll never have the password. Also, the current login forms are incompatible with standard form login (j_security_check,..). So do we have different templates or make the Wiki login form call the standard login action. And so on.... Maybe I am just too ignorant of the inner working of JSPWiki. Feel free to explain how all this would be handled without make changes to existing classes.

Janne has done a good job of creating a comprehensive system. Look at Container Managed Security for a brief overview, and look at Auth Plugin for how I did it for the 2.0.x JSPWiki. Not recommended, but if you need to have this, you are welcome to build on my efforts. -- FosterSchucker

I'd like to move the discussion about Container Managed Security to Container Managed Security Discussion, and leave this page for the 2.1.x changes. I've put some comments over there. -- FosterSchucker


DaveBrondsema, 4-22-04

I'd like to configure the login timeout from jspwiki.properties. And it'd be nice if you could use 0 to specify never time out.

To answer my own question, add:

<session-config>
  <session-timeout>60</session-timeout>
</session-config>
to WEB-INF/web.xml before <welcome-file-list>. The number is the number of minutes.
AnthonyWilkinson, 2004-08-09 There's a JavaScript error in the current alpha version when you enter an edit screen without having logged on because the script is accessing the form by it's ordinal (first form) rather than by name. Since the login form appears on the left menu it's changing the position of the relevant form.

As a related point - is there any way to turn off authentication completely? Sorry if this is answered somewhere else but I couldn't find it if it is. I would be interested in getting authentication going later (possibly using LDAP). At the moment, however, I just want to get the wiki up to a later version to take advantage of some of the other features without spending a lot of time writing LDAP plugins, etc.


EliasTorres 2004-02-17

First I wanted to say thanks for such a quite useful and well-done java project. I had an immediate need for per-page ACLs so I went directly to the latest version CVS and found almost everything implemented. I did a mixture of J2EE authentication and Custom UserDatabase to get the results I wanted. However, I found the checkPermissions function in PageAuthorizer a bit confusing in the way that it decided ACLs. I just spent a little bit of time looking at Apache's directives for allow,deny http://httpd.apache.org/docs/mod/mod_access.html and was able to quickly implement it. I'm suggesting JSPWiki may do the same. I do not know much about JSPWiki and I've been reading the Wiki as much as I could, this may be completely incompatible with the plans, but if you find it interesting great if not, I'm sure what you'll end up releasing will be great like everything else in JSPWiki.

If allow,deny the default is to deny access if you don't meet the criteria. Deny,allow the default is to grant access if you are not explicitly listed. The allow,deny will do all the ALLOWs first, then the DENYs and viceversa.

This one denies everything except for KnownPerson viewing.

[{ORDER allow,deny}]
[{ALLOW view KnownPerson}]

This one allows everything, except for Guest editing.

[{ORDER deny,allow}]
[{DENY edit Guest}]

This was a slight modification to TranslatorReader to parse the new ORDER attribute. AccessControlList also needed a getter/setter and a new implementation for checkPermissions that did stuff accordingly.


Cookie problem...#

I'm using AAA on a wiki. I seem to get frequently 'logged out' and I become 'anonymous'. I've checked my cookies, and whilst there is a JSESSIONID cookie, there is not one called JSPWikiAssertedName - which the documentation implies is required. Even when I am logged in. Any ideas?

Cheers --AdamSmith

Add new attachment

Only authorized users are allowed to upload new attachments.
« This page (revision-44) was last changed on 25-Aug-2006 14:27 by Candid Dauth