Category Archives: JSPWiki

Configuring a public JSPWiki instance for private use

Been a tad quiet on this blog for a while I realise – time to freshen thing up a bit.

In this blog post we’re going to quickly cover how to configure a JSPWiki instance such that wiki content cannot be viewed without being authenticated with a login account. For example, you may wish to deploy JSPWiki in the cloud for convenient access anywhere, but also use it to host company-sensitive documentation. In this case you probably don’t want the general public even having read-only access to the wiki content.

It turns out this is very straightforward to achieve and merely consists of making the desired changes in the jspwiki.policy file. The function of each policy block within jspwiki.policy is also clearly documented in the same file, so everything is pretty self explanatory.

JSPWiki setup and configuration is outside the scope of this post, so I’m assuming you’ve set up JSPWiki to use container-managed authentication similar to some of my previous articles here. Also note that in recent releases of JSPWiki (certainly v2.10.x) the location of various configurations files has changed – again, outside the scope of this post. All this considered, the following full excerpt of my jspwiki.policy file achieves the following:

  • All public users are prevented from being able to view the wiki.
  • Anonymous users have no permissions.
  • Users authenticated via a browser cookie have no permissions.
  • Users authenticated with a JSPWiki login account (configured in our application server, e.g. GlassFish) have a set of standard permissions for viewing, editing, and modifying content.
  • Admin users have full permissions.

Note that I’ve left the original policy blocks in place commented out so you can see the exact settings I’ve made.


//  Licensed to the Apache Software Foundation (ASF) under one
//  or more contributor license agreements.  See the NOTICE file
//  distributed with this work for additional information
//  regarding copyright ownership.  The ASF licenses this file
//  to you under the Apache License, Version 2.0 (the
//  "License"); you may not use this file except in compliance
//  with the License.  You may obtain a copy of the License at
//
//    http://www.apache.org/licenses/LICENSE-2.0
//
//  Unless required by applicable law or agreed to in writing,
//  software distributed under the License is distributed on an
//  "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
//  KIND, either express or implied.  See the License for the
//  specific language governing permissions and limitations
//  under the License.

// $Id: jspwiki.policy,v 1.23 2007-07-06 10:36:36 jalkanen Exp $
//
// This file contains the local security policy for JSPWiki.
// It provides the permissions rules for the JSPWiki
// environment, and should be suitable for most purposes.
// JSPWiki will load this policy when the wiki webapp starts.
//
// As noted, this is the 'local' policy for this instance of JSPWiki.
// You can also use the standard Java 2 security policy mechanisms
// to create a consolidated 'global policy' (JVM-wide) that will be checked first,
// before this local policy. This is ideal for situations in which you are
// running multiple instances of JSPWiki in your web container.
// To set a global security policy for all running instances of JSPWiki,
// you will need to specify the location of the global policy by setting the
// JVM system property 'java.security.policy' in the command line script
// you use to start your web container. See the documentation
// pages at http://doc.jspwiki.org/2.4/wiki/InstallingJSPWiki. If you
// don't know what this means, don't worry about it.
//
// Also, if you are running JSPWiki with a security policy, you will probably
// want to copy the contents of the file jspwiki-container.policy into your
// container's policy. See that file for more details.
//
// ------ EVERYTHING THAT FOLLOWS IS THE 'LOCAL' POLICY FOR YOUR WIKI ------

// The first policy block grants privileges that all users need, regardless of
// the roles or groups they belong to. Everyone can register with the wiki and
// log in. Everyone can edit their profile after they authenticate.
// Everyone can also view all wiki pages unless otherwise protected by an ACL.
// If that seems too loose for your needs, you can restrict page-viewing
// privileges by moving the PagePermission 'view' grant to one of the other blocks.

//grant principal org.apache.wiki.auth.authorize.Role "All" {
//    permission org.apache.wiki.auth.permissions.PagePermission "*:*", "view";
//    permission org.apache.wiki.auth.permissions.WikiPermission "*", "editPreferences";
//    permission org.apache.wiki.auth.permissions.WikiPermission "*", "editProfile";
//    permission org.apache.wiki.auth.permissions.WikiPermission "*", "login";
//};

grant principal org.apache.wiki.auth.authorize.Role "All" {
    permission org.apache.wiki.auth.permissions.WikiPermission "*", "editPreferences";
    permission org.apache.wiki.auth.permissions.WikiPermission "*", "editProfile";
    permission org.apache.wiki.auth.permissions.WikiPermission "*", "login";
};


// The second policy block is extremely loose, and unsuited for public-facing wikis.
// Anonymous users are allowed to create, edit and comment on all pages.
//
// Note: For Internet-facing wikis, you are strongly advised to remove the
// lines containing the "modify" and "createPages" permissions; this will make
// the wiki read-only for anonymous users.

// Note that "modify" implies *both* "edit" and "upload", so if you wish to
// allow editing only, then replace "modify" with "edit".

//grant principal org.apache.wiki.auth.authorize.Role "Anonymous" {
//    permission org.apache.wiki.auth.permissions.PagePermission "*:*", "modify";
//    permission org.apache.wiki.auth.permissions.WikiPermission "*", "createPages";
//};

grant principal org.apache.wiki.auth.authorize.Role "Anonymous" {
};


// This next policy block is also pretty loose. It allows users who claim to
// be someone (via their cookie) to create, edit and comment on all pages,
// as well as upload files.
// They can also view the membership list of groups.

//grant principal org.apache.wiki.auth.authorize.Role "Asserted" {
//    permission org.apache.wiki.auth.permissions.PagePermission "*:*", "modify";
//    permission org.apache.wiki.auth.permissions.WikiPermission "*", "createPages";
//    permission org.apache.wiki.auth.permissions.GroupPermission "*:*", "view";
//};

grant principal org.apache.wiki.auth.authorize.Role "Asserted" {
};


// Authenticated users can do most things: view, create, edit and
// comment on all pages; upload files to existing ones; create and edit
// wiki groups; and rename existing pages. Authenticated users can also
// edit groups they are members of.

grant principal org.apache.wiki.auth.authorize.Role "Authenticated" {
    permission org.apache.wiki.auth.permissions.PagePermission "*:*", "modify,rename";
    permission org.apache.wiki.auth.permissions.GroupPermission "*:*", "view";
    permission org.apache.wiki.auth.permissions.GroupPermission "*:<groupmember>", "edit";
    permission org.apache.wiki.auth.permissions.WikiPermission "*", "createPages,createGroups";
};


// Administrators (principals or roles possessing AllPermission)
// are allowed to delete any page, and can edit, rename and delete
// groups. You should match the permission target (here, 'JSPWiki')
// with the value of the 'jspwiki.applicationName' property in
// jspwiki.properties. Two administative groups are set up below:
// the wiki group "Admin" (stored by default in wiki page GroupAdmin)
// and the container role "Admin" (managed by the web container).

grant principal org.apache.wiki.auth.GroupPrincipal "Admin" {
    permission org.apache.wiki.auth.permissions.AllPermission "*";
};
grant principal org.apache.wiki.auth.authorize.Role "Admin" {
    permission org.apache.wiki.auth.permissions.AllPermission "*";
};

After applying this and restarting the application server domain, one can now see that we need to authenticate even to view any of the wiki content.

JSPWiki now requires authentication to view.

Enjoy, and if you have any problems please leave a comment.

Advertisements

Creating a GlassFish service on Mac OS X

Quick post – when installing GlassFish 3.1.2.2 on Mac OS X (10.8.3 in my case) a GlassFish service won’t be created by the GlassFish installer (whereas Windows and Solaris platforms do get the ability to manage GlassFish as a service).

I came across a handy blog post by a former Sun Microsystems staffer which takes us most of the way there:

http://lowbittest.wordpress.com/2007/11/06/running-glassfish-on-mac-os-x-using-launchd/

The original blog entry was pertaining to Mac OS 10.4 but applies to 10.8 with one exception (in my case). When attempting to load the service the GlassFish process would immediately be killed by launchd. This is alluded to in the blog comments above.

The solution can be found at https://discussions.apple.com/thread/1744853?start=0&tstart=0 and consists of adding the following entry to your GlassFish plist file:

<key>AbandonProcessGroup</key>
<true/>

 

My quick procedure for creating a GlassFish service based on the above information follows. Note that I am not covering the details of how services are created and managed for Mac OS, so this is basically to get up and running quickly.

1) Create a plist file

Simlar to Solaris SMF, the plist file is an XML service descriptor file. These are the contents of my file:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple Computer//DTD PLIST 1.0//EN"
"http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>Label</key>
<string>com.sun.glassfish</string>
<key>Disabled</key>
<false/>
<key>UserName</key>
<string>davek</string>
<key>GroupName</key>
<string>staff</string>
<key>ProgramArguments</key>
<array>
<string>/Users/davek/glassfish3/bin/asadmin</string>
<string>start-domain</string>
<string>domain1</string>
</array>
<key>RunAtLoad</key>
<true/>
<key>AbandonProcessGroup</key>
<true/>
</dict>
</plist>

Replace the UserName and GroupName values with the user and group you wish to launch GlassFish as. Also, GlassFish in my case has been installed to /Users/davek/glassfish3 – alter this path in your plist file accordingly.

Save the file for example as GlassFish.plist and copy it to /Library/LaunchDaemons.

 

2) Set ownership on the GlassFish domain

We are running the GlassFish service as davek:staff so be sure to change ownership on the relevant GlassFish domain (domain1 in this example) to match.

 

3) Import the service

Run the following command:

sudo launchctl load /Library/LaunchDaemons/GlassFish.plist

The service starts automatically after importing, so you should be able to browse to the administrative interface for the domain. If you reboot the system, the domain should also start on boot automatically.

Prevent the “List of attachments” from appearing in documents printed from JSPWiki

In a default installation of JSPWiki files attached to a JSPWiki page are printed in a list along with the rest of the document. If one has a large amount of attached files in a wiki page, this leads to needless extra printed pages:

List of attached files in a document printed from JSPWiki

I enquired about this on the JSPWiki users mailing list, and Dirk Frederickx kindly gave me the solution to this:

“Following changes to the jspwiki_print.css file, in the “templates/default” directory, will hide the attachment list:”

/* add this line to hide the List of Attachments */
#attach {display:none;}

And, it works a charm.

Fun with JSPWiki skins

I really love JSPWiki. It’s super-easy to install, doesn’t require any additional configuration for a back-end database, the native interface is quick and fast to use, and it just runs and runs. Great software.

If there’s one area however where it’s lacking, it’s in a nice selection of bundled good-looking themes. But hey, it’s free and open source software, so one is really in no position to complain – and new skins can be created using entirely standard and familiar HTML and CSS.

It’s worth noting the difference between JSPWiki templates and skins – described at http://www.jspwiki.org/wiki/JSPWikiSkinDesign

After a bit of tinkering with CSS and the bundled “Smart” theme, I came up with this:

JSPWiki - modified "Smart" theme

Not the stuff of professional web design, but a definite improvement on the default theme, in my humble opinion.

Enable secure LDAP container based authentication with JSPWiki

A quick follow up on my post here. I will describe below the steps needed to enable secure LDAP authentication (both LDAPS and HTTPS). This is not intended for production use, obviously.

I’m using the same platform and environment described here, and also using this as the starting point for the following.

 

Verify that the LDAPS connection handler is enabled in OpenDJ

This can be checked using the OpenDJ Control Panel GUI, and modified if necessary using the CLI dsconfig utility.

 

Switch to the secure LDAP port in the GlassFish JSPWiki security realm

Make sure you are using the ldaps:// URL prefix, and specify the secure port number (1636 in this example):

Enable LDAPS in GlassFish

 

Enable security for the relevant GlassFish HTTP network listener port

Our JSPWiki application is listening over port 8080, configured in GlassFish under http-listener-1. Enable security for this port:

Enabling security for the GlassFish http-listener-1 network listener

 

Enable HTTPS connections to JSPWiki

This is performed via modification of the JSPWiki web.xml file. In a default state, the web.xml file contains the following entries which enable the use of SSL connections:

<user-data-constraint>
           <transport-guarantee>CONFIDENTIAL</transport-guarantee>
</user-data-constraint>

Ensure these exist in web.xml under the container managed authentication section.

 

Export the OpenDJ SSL certificate and import it into the JSPWiki JKS keystore

The keytool CLI utility is used for this step.

First, we export the OpenDJ certificate (which has a default alias of server-cert) to a file:

dave@mymachine:~/OpenDJ/config$ pfexec keytool -export -alias "server-cert" -keystore ~/OpenDJ/config/keystore -file /tmp/server-cert.cer
Enter keystore password:  

Certificate stored in file </tmp/server-cert.cer>

Next, we import the certificate file into the keystore of the GlassFish domain running our instance of JSPWiki, which in this example is at /opt/glassfishv3/glassfish/domains/domain1/config/cacerts.jks:

dave@mymachine:~/OpenDJ/config$ pfexec keytool -import -v -trustcacerts -alias "server-cert" -keystore /opt/glassfishv3/glassfish/domains/domain1/config/cacerts.jks -file /tmp/server-cert.cer 
Enter keystore password:  
Owner: CN=mymachine, O=OpenDS Self-Signed Certificate
Issuer: CN=mymachine, O=OpenDS Self-Signed Certificate
Serial number: 
Valid from: 
Certificate fingerprints:
	 MD5:  
	 SHA1: 
	 Signature algorithm name: SHA1withRSA
	 Version: 3
Trust this certificate? [no]:  yes
Certificate was added to keystore
[Storing /opt/glassfishv3/glassfish/domains/domain1/config/cacerts.jks]

 

Modify the jspwiki.baseURL value

This is required as the URL prefix will have changed from http:// to https://. This modification is performed in the jspwiki.properties file.

Assuming my existing jspwiki.baseURL value is:

http://192.168.1.1:8080/ITProjects/

This would need to be changed to:

https://192.168.1.1:8080/ITProjects/

 

Restart the GlassFish domain, and test LDAP logins…

…and if you don’t observe secure logins working as they should, leave a comment.

Container based authentication with JSPWiki, GlassFish and OpenDJ

In this blog entry I am going to describe configuring JSPWiki to use container based authentication to authenticate LDAP users existing in an OpenDJ directory. I am using GlassFish as my web application container, so this can be considered an alternative solution to using Tomcat, for example as described here.

 

I am running JSPWiki version 2.8.3, deployed in GlassFish Open Source Edition 3.1.1 (build 12) on OpenIndiana oi_151 x86. OpenDJ is version 2.4.4, and I am using Java 6 update 26.

I am assuming prior basic familiarity with installing, configuring, and managing GlassFish and OpenDJ. Our starting point will be a freshly deployed instance of JSPWiki, for which the initial first-run setup procedure has taken place and without any configuration to the JSPWiki configuration files.

This is an insecure setup intended for testing purposes.

 

Create user and admin groups for JSPWiki in OpenDJ

I have created the Groups OU under my Base DN, and within it created the groups wiki-admin and wiki-users.

Members of the wiki-admin group will be authorized with full permissions in JSPWiki once authenticated. Members of the wiki-users group however will have a lesser set of permissions, suitable for regular day-to-day use of the wiki. You can use LDIF commands if you wish to create the directory entries, however, I just use OpenDJ’s super-easy GUI to do the work. For example:

JSPWiki groups in OpenDJ

 

Create an LDAP security realm in GlassFish

This can be performed in the GlassFish admin BUI. Note that we perform this step under the Configurations -> server-config node in the BUI (not the Configurations -> default-config node):

GlassFish server-config node

I have created the LDAP realm JSPWikiUsers with the following settings:

GlassFish LDAP security realm settings

Some observations on the above can be noted here:

  • The search-bind-dn and search-bind-password properties may be optional for your OpenDJ installation: they are required in my case because I have disabled anonymous access to my OpenDJ server
  • The port used for access to your OpenDJ server may not necessarily be 1389 – change this as necessary.

 

Change the JACC provider from default to simple

I found that if this step is not performed, LDAP group lookup from GlassFish to OpenDJ will plain just not work.

Navigate to the Configurations -> server-config -> Security node of the GlassFish admin BUI and make the setting as illustrated:

GlassFish - set the JACC provider to Simple

 

This should be all the configuration needed in GlassFish using the admin BUI, so we can now proceed to making the required modifications to the following JSPWiki deployment descriptor and policy files:

  • web.xml
  • jspwiki.policy
  • glassfish-web.xml

 

In the following steps, we are assuming that JSPWiki has been deployed to the domain1 domain, and the path to the deployment descriptor and policy configuration files is:

/opt/glassfishv3/glassfish/domains/domain1/applications/JSPWiki/WEB-INF

 

(Also, in my case no changes needed to be made at all to the jspwiki.properties file.)

 

Enable container based authentication in the web.xml file

In the web.xml file (in its unmodified state in JSPWiki v2.8.3), look for the section near the end of the file which begins with the following comment:

<!--  REMOVE ME TO ENABLE CONTAINER-MANAGED AUTH

 

Simply uncomment the section and replace it with the following:

<security-constraint>
       <web-resource-collection>
           <web-resource-name>Administrative Area</web-resource-name>
           <url-pattern>/Delete.jsp</url-pattern>
       </web-resource-collection>
       <auth-constraint>
           <role-name>wiki-admin</role-name>
       </auth-constraint>
   </security-constraint>
      
   <security-constraint>
       <web-resource-collection>
           <web-resource-name>Authenticated area</web-resource-name>
           <url-pattern>/Edit.jsp</url-pattern>
           <url-pattern>/Comment.jsp</url-pattern>
           <url-pattern>/Login.jsp</url-pattern>
           <url-pattern>/NewGroup.jsp</url-pattern>
           <url-pattern>/Rename.jsp</url-pattern>
           <url-pattern>/Upload.jsp</url-pattern>
           <http-method>DELETE</http-method>
           <http-method>GET</http-method>
           <http-method>HEAD</http-method>
           <http-method>POST</http-method>
           <http-method>PUT</http-method>
       </web-resource-collection>

       <web-resource-collection>
           <web-resource-name>Read-only Area</web-resource-name>
           <url-pattern>/attach</url-pattern>
           <http-method>DELETE</http-method>
           <http-method>POST</http-method>
           <http-method>PUT</http-method>
       </web-resource-collection>

       <auth-constraint>
           <role-name>wiki-admin</role-name>
           <role-name>wiki-users</role-name>
       </auth-constraint>
   </security-constraint>

   <login-config>
       <auth-method>FORM</auth-method>
       <realm-name>JSPWikiUsers</realm-name>
       <form-login-config>
           <form-login-page>/LoginForm.jsp</form-login-page>
           <form-error-page>/LoginForm.jsp</form-error-page>
       </form-login-config>
   </login-config>

   <security-role>
       <description>
           This logical role includes all authenticated users
       </description>
       <role-name>wiki-users</role-name>
   </security-role>

   <security-role>
       <description>
           This logical role includes all administrative users
       </description>
       <role-name>wiki-admin</role-name>
   </security-role>

 

Modify the jspwiki.policy file

This will allow users in the wiki-admin LDAP group to be granted full permissions upon authenticating to JSPWiki.

Look for the following section at the end of the jspwiki.policy file (in its unmodified state in a JSPWiki v2.8.3 installation):

// Administrators (principals or roles possessing AllPermission)
// are allowed to delete any page, and can edit, rename and delete
// groups. You should match the permission target (here, 'JSPWiki')
// with the value of the 'jspwiki.applicationName' property in
// jspwiki.properties. Two administative groups are set up below:
// the wiki group "Admin" (stored by default in wiki page GroupAdmin)
// and the container role "Admin" (managed by the web container).

grant principal com.ecyrd.jspwiki.auth.GroupPrincipal "Admin" {
    permission com.ecyrd.jspwiki.auth.permissions.AllPermission "*";
};
grant principal com.ecyrd.jspwiki.auth.authorize.Role "Admin" {
    permission com.ecyrd.jspwiki.auth.permissions.AllPermission "*";
};

 

And modify it to read:

// Administrators (principals or roles possessing AllPermission)
// are allowed to delete any page, and can edit, rename and delete
// groups. You should match the permission target (here, 'JSPWiki')
// with the value of the 'jspwiki.applicationName' property in
// jspwiki.properties. Two administative groups are set up below:
// the wiki group "Admin" (stored by default in wiki page GroupAdmin)
// and the container role "Admin" (managed by the web container).

// grant principal com.ecyrd.jspwiki.auth.GroupPrincipal "Admin" {
//     permission com.ecyrd.jspwiki.auth.permissions.AllPermission "*";
// };
// grant principal com.ecyrd.jspwiki.auth.authorize.Role "Admin" {
//     permission com.ecyrd.jspwiki.auth.permissions.AllPermission "*";
// };
grant principal com.ecyrd.jspwiki.auth.authorize.Role "wiki-admin" {
    permission com.ecyrd.jspwiki.auth.permissions.AllPermission "*";
};

 

Create the glassfish-web.xml file

The primary purpose of this file will be to map the security roles we defined in the web.xml file to the JSPWiki groups we created in OpenDJ. The file should be created at:

/opt/glassfishv3/glassfish/domains/domain1/applications/JSPWiki/WEB-INF

 

The glassfish-web.xml file should contain the following only:

<!DOCTYPE glassfish-web-app PUBLIC "-//GlassFish.org//DTD GlassFish Application Server 3.1 Servlet 3.0//EN" "http://glassfish.org/dtds/glassfish-web-app_3_0-1.dtd">

<glassfish-web-app>
 <security-role-mapping>
        <role-name>wiki-admin</role-name>
        <group-name>wiki-admin</group-name>
 </security-role-mapping>
 <security-role-mapping>
        <role-name>wiki-users</role-name>
        <group-name>wiki-users</group-name>
 </security-role-mapping>
</glassfish-web-app>

 

Restart the GlassFish domain, and test LDAP logins to JSPWiki

First, restart the domain either using the asadmin utility or the GlassFish admin BUI. Then test LDAP logins to JSPWiki.

In my case, we can observe that logging in as a user that is a member of the wiki-admin group in OpenDJ, I do indeed have full permissions in JSPWiki:

JSPWiki LDAP admin user

Whereas logging in as a user that is a member of the wiki-users group in OpenDJ, I am restricted from certain destructive actions:

JSPWiki LDAP standard user

Apache Roller 5 problems on GlassFish 3.0.1

I recently installed Apache Roller 5 on GlassFish 3.0.1 (on an OpenIndiana host with JDK 6u26, connecting to a PostgreSQL 8.4 database) and had the rather unusual behaviour of the Roller web app seemingly failing after an arbitrary period of time, followed by the GlassFish domain itself stopping.

I have two GlassFish domains set up on the host in question, one serving up JSPWiki, the other serving Roller. The JSPWiki domain remained stable, so I figured this was possibly either a problem with Roller 5.0 or a port conflict issue between the two domains. Even after recreating the second domain with the –portbase option and ensuring there were no conflicting ports, Roller would still eventually crap out followed by the domain itself, with seemingly nothing of relevance logged.

I upgraded to GlassFish 3.1.1 and so far things are perfectly stable – so I guess this was due to some issue with GlassFish 3.0.1 in the end.

Apache Roller 5 running the Lightword theme

I’m giving back to open source communities – are you?

Open source has brought a lot of happiness into my life – exposure to cutting edge technology (thanks Sun Microsystems), an awesome no-cost operating system (running rings around the proprietary alternatives) for me, my friends and family, and thousands upon thousands of applications which allow me to perform practically any computing task imaginable, from the creative to the commonplace.

I’ve often thought about the ways I could contribute back – but given my limited funds and lack of coding chops, what could I possibly do to help out in the communities from which the products I use and enjoy originate?

Well, I’m proud to say I’ve found a way – and I now invest a sizeable amount of time in private to assist with the documentation efforts for Open Wonderland and Ekiga. In the case of Open Wonderland, large amounts of legacy documentation on Java.net (following Oracle’s abandonment of the project) need to be migrated to a community-run instance of JSPWiki (itself an open source wiki engine which comes highly recommended, by the way). For Ekiga, there is already a wealth of excellent documentation, but it’s spread out over a number of different locations, and needs updating and tidying up.

Either way, it’s a great feeling to be giving something worthwhile back, and knowing that other people out there really can benefit from the work of a non-developer. 🙂