This is version . It is not the current version, and thus it cannot be edited.
[Back to current version]   [Restore this version]

Authentication is the process of logging in, and making sure that the user actually is who he says he is. Authorization, or access control, defines the rights and permissions of users, be they unauthenticated guests or known and authenticated individuals. While the two are separate problems from an architecture perspective, an administrator usually considers them jointly. Thus, this combined status and instruction page.

Current status: early alpha. Only available in CVS.#

JSPWiki version 2.1.51 is slowly acquiring auth capabilities. Under development by Janne. Syntax may still change.

User authentication and authorization works; groups don't. Only the three default groups Guest, NamedGuest, and KnownPerson are currently usable.

JSPWiki developers are invited to collect their observations on the Auth* scheme on Authorization and Authentication Development.

Setting up user authentication#

Add the following properties to

  jspwiki.authenticator = FileAuthenticator

  jspwiki.fileAuthenticator.fileName = /tmp/passwords.txt

Edit the password file:

  # The format is simply username = password
  # No encryption is used currently.
  # Comments are allowed; prepend with hash.
  ebu = foobar
  ubi = frobozz

Restart the container, and access the main page. If you use the default template, a small login box should appear in the left margin. Enter the username in the upper box and the password in the lower, and click on login. If you see the friendly greeting, you have authenticated successfully.


FileAuthenticator is a fairly simple class (com.ecyrd.jspwiki.auth.modules.FileAuthenticator). You can write your own class to implement com.ecyrd.jspwiki.auth.WikiAuthenticator, make sure the webapp can find the class, and use the full class name for the jspwiki.authenticator property to do your own, custom authentication.

About Groups#

Group support is not finished at this time. Three system groups are defined:

  • anyone accessing the wiki belongs to group Guest
  • anyone who has set their name on the user preferences page belongs to group NamedGuest
  • anyone who has been authenticated belongs to group KnownPerson

In the future, the default method to create a group Xyzzy with members Foo and Bar is to

  • create a page called Xyzzy
  • on the page, add the statement [{SET members='Foo, Bar'}]
Naturally, a custom can be substituted, if you wish to look group information up in some other manner.


Groups actually work if you don't use the prospective default implementation (WikiDatabase) that uses WikiPages for group definition. I wrote a minor patch to UserManager, now available in the CVS HEAD. You can now define the property jspwiki.userdatabase = and plug in a com.ecyrd.jspwiki.auth.UserDatabase implementation. Again, this is a fairly simple operation, but expect to adjust for Janne's changes before any version releases.


Page Access Rules#

Plugin-like entries on a page define the access level of users. The following examples illustrate the syntax:

A publicly viewable page (since everyone belongs to group Guest, editable only by users ebu and ubi:

  [{ALLOW view Guest}]
  [{DENY edit Guest}]
  [{ALLOW edit ebu, ubi}]

A page viewable by ebu and ubi only, editable by ebu only:

  [{DENY view Guest}]
  [{ALLOW view ebu, ubi}]
  [{DENY edit Guest}]
  [{ALLOW edit ebu}]

As can be seen from the parameters, both usernames and group names can be specified in access rules. (We just can't specify new groups quite yet.) Note that edit does not imply view, and that the order of inclusion-exclusion does not matter. Positive permission takes precedence.

Default Access Rules#

Theoretically, creating a page named DefaultPermissions and placing a set of access rules on it should make those rules apply to all pages. Page-specific access rules should replace the defaults, if present. However, the default system does not seem to work properly, and is liable to change (at least into a more configurable form).


Administrators are people who are allowed to do whatever they please in the wiki system. No access rights stop them.

You can set the name of the administrator group by setting the jspwiki.auth.administrator -property in your For example:

jspwiki.auth.administrator = WikiAdmin

The default value for the admin group is "WikiAdmin".

On the group page you would then list those people who are a part of this group. For example, to make JackJones and JillJones administrators, use:

[{SET members='JackJones, JillJones'}]


Multiple Wiki Site Security#

Hmm, any indications on how security and such can be setup and administered on say a wiki installation of 8 wiki's with about 20 users? Am I going to have massive duplication and have to manually synch stuff between the wiki's? Any way to setup a master security configuration and have it propagate thru each wiki? (Tangentially related to my SecurityHelp question.) --JohnV

User/password databases can be shared. The default PageAuthorizer finds its permissions on the WikiPages themselves. --JanneJalkanen

Limitting Access to Wiki to Particular Users#

How do i make it so only certain users can get access to the wiki at all? When i deny guest view priviledges i get a loop error in when access in the wiki. Allowing guest to view fixes this, but it also means guests can view pages and i don't want them to.

Create a page named LoginError and give Guest view permissions on it. --Killer

Thanks but can you explain what this accomplishes?

That accomplishes the behaviour you are looking for. In that case you can globally deny view from Guest and they will get a nice explanation saying why they cannot see anything. --Killer

Container Managed Security#

How do you integrate Container Managed Security with JspWiki 2.2 Authentication/Authorization?
(I am not sure why everyone wants to create yet another set of usernames/passwords/security problems, etc.)

I turn on the security constraint in the web.xml. When a WikiPage has a page access rule set, it throws a login error and takes you to the login page. However the login page doesn't work with container managed security. So you can never login. That is, unless you set up a separate JspWiki authorization scheme like FileAuthenticator. So you end up with two competing authorization schemes.

  • For howto secure web applications in JBoss see SecureTheJmxConsole. I've done the same for JspWiki and it's really easy. -- JJarkko
uhhh... and that's relevant how? I am not asking how to secure a web application in JBoss and I can already lock JspWiki 2.0 down using contain manager security but that's not anything integrated into the 2.2 authorization scheme (AFAIK). I am asking something specific about JspWiki 2.2 Authentication/Authorization. It would appear that it requires writing a JspWiki authentication plugin, which I haven't look into yet, in order to avoid yet another place for user names and passwords. Although, it seems so basic to me that it should be included as well as be default authentication scheme. And maybe it already works, so that's why I am asking before I go off and write something. If I misunderstand and you have actually written the plugin already then please share it.
  • Hmm, let me try to explain things ;) If you secure your application according to the above link you get both Authentication and data needed for Authorization for the current user from the container (basic J2EE Servlet stuff). Then you can ask from the servlet container if the user has the specified role by using the HttpServletRequest.isUserInRole and thus allow access if the user has the required role,as defined with the ALLOW method above, or disallow access in the case of DENY. Name of the authenticated user is available from request.getUserPrincipal. IMHO the application doesn't have to know anything about where the login-user-name or his/hers role/group information came from. The only problem with CMS is that you need to use tools specific to the container/server to setup users,passwords and group information. Which isn't a problem if you just choose your backend carefully enough (e.g. database with simple schema or use LDAP). There's also securityfilter project which tries to mimic container manager security. I don't know if it's any use but the site contains some information and discussion about J2EE/JSP/Servlet security related stuff. I haven't written any plugins for JspWiki, i've just found it and i'm very happy! ;) --jjarkko
  • I think the requirement is really for a Container manager adapter for 2.2 auth model. Someone would need to write it - any volunteers? --JanneJalkanen
  • I am also interessed in using JSPWiki with CMS but it does not seem to be consistenly implemented in all containers. Tomcat provides a principal if the user once is authenticated. JBoss only provides the principal for pages in the secured context. I found something about this problem here: -- MDeichsel

Default Access Rules#

Since the page for default access rules applies to all pages, how do you set the access rules for the default access rules page. I want it so only WikiAdmin users can change the default access rules but since my default access rules are,

  [{ALLOW view Guest}]
  [{ALLOW edit NamedGuest}]
  [{DENY edit Guest}]
, anyone can edit the page and change them that is a NamedGuest. I do not know how to secure only the DefaultPermissions page. Someone on my wiki keeps changing the default permissions. I want to keep them set. Possible? --JPS

--Fixed in JSPWiki v2.1.104. Thanks alot. It works great. --JPS

Old discussion: Requirements for JSPWiki Authentication

Category Development - to be moved to Documentation once auth* is ready.

Add new attachment

Only authorized users are allowed to upload new attachments.
« This particular version was published on 06-Aug-2004 20:38 by JPS.