Security Configuration Verifier

This page examines JSPWiki's security configuration and tries to determine if it is working the way it should. Although JSPWiki comes configured with some reasonable default configuration settings out of the box, it's not always obvious what settings to change if you need to customize the security... and sooner or later, just about everyone does.

This page is dynamically generated by JSPWiki. It examines the authentication, authorization and security policy settings. When we think something looks funny, we'll try to communicate what the issue might be, and will make recommendations on how to fix the problem.

Please delete this JSP when you are finished troubleshooting your system. This diagnostic data presented on this page do not represent a security risk to your system per se, but they do provide a significant amount of contextual information that could be useful to an attacker. This page is unconstrained, which means that anyone can view it: nice people, mean people and everyone in between. You have been warned.

Authentication Configuration

Container-Managed Authentication

Container-managed authentication appears to be disabled, according to your WEB-INF/web.xml file.

JAAS Login Configuration

JSPWiki uses JAAS to define the authentication process. We need to be able to locate a JAAS configuration file. The default location is WEB-INF/jspwiki.jaas), and its location is specified by the java.security.auth.login.config system property.

Good news:
  • The system property 'java.security.auth.login.config' is set to: file:/usr/local/apache-tomcat-5.5.17/webapps/wiki/WEB-INF/jspwiki.jaas.
  • File 'file:/usr/local/apache-tomcat-5.5.17/webapps/wiki/WEB-INF/jspwiki.jaas' exists in the filesystem.
Note: this instance of JSPWiki set the system property at startup.

Inside the JAAS config file, we must be able to find two login configurations: JSPWiki-container and JSPWiki-custom.

Good news:
  • We found the 'JSPWiki-container' login configuration.
  • We found the 'JSPWiki-custom' login configuration.

Authorization Configuration

Container-Managed Authorization

Container-managed authorization appears to be disabled, according to your WEB-INF/web.xml file.

Security Policy

JSPWiki's authorizes user actions by consulting a standard Java 2 security policy file. By default, JSPWiki installs its standard policy file at startup time by setting the system property.java.security.policy and then refreshing the system policy. However, because many application servers and other Java applications sometimes also set their own policies, JSPWiki will respect the system property if it is already set.

Good news:
  • The system property 'java.security.policy' is set to: file:/usr/local/apache-tomcat-5.5.17/webapps/wiki/WEB-INF/jspwiki.policy.
  • File 'file:/usr/local/apache-tomcat-5.5.17/webapps/wiki/WEB-INF/jspwiki.policy' exists in the filesystem.
Note: this instance of JSPWiki set the system property at startup.

Now we are going to validate the security policy file. To do this, we parse the security policy and examine each grant block. If we see a permission entry that is signed, we verify that the certificate alias exists in our keystore. The keystore itself must also exist in the file system. And as an additional check, we will try to load each Permission class into memory to verify that JSPWiki's classloader can find them.

Good news:
  • The security policy '/usr/local/apache-tomcat-5.5.17/webapps/wiki/WEB-INF/jspwiki.policy' exists.
  • The security policy specifies a keystore, and we were able to locate it in the filesystem.
  • The security policy looks fine.

Access Control Validation

Security Policy Restrictions

Now comes the really fun part. Using the current security policy, we will test the PagePermissions each JSPWiki role possesses for a range of pages. The roles we will test include the standard JSPWiki roles (Authenticated, All, etc.) plus any others you may have listed in the security policy. In addition to the PagePermissions, we will also test the WikiPermissions. The results of these tests should tell you what behaviors you can expect based on your security policy file. If we had problems finding, parsing or verifying the policy file, these tests will likely fail.

The colors in each cell show the results of the test.  Green  means success;  red  means failure. Hovering over a role name or individual cell will display more detailed information about the role or test.

Permission All Anonymous Asserted Authenticated Admin Admin
v e m r d v e m r d v e m r d v e m r d v e m r d v e m r d
PagePermission "wiki:Main"                                                            
PagePermission "wiki:Index"                                                            
PagePermission "wiki:GroupTest"                                                            
PagePermission "wiki:GroupAdmin"                                                            
WikiPermission "wiki","createGroups"            
WikiPermission "wiki","createPages"            
WikiPermission "wiki","login"            
WikiPermission "wiki","editPreferences"            
WikiPermission "wiki","editProfile"            
AllPermission "wiki"            
Important: these tests do not take into account any page-level access control lists. Page ACLs, if they exist, will contrain access further than what is shown in the table.

User Database

Database Configuration

The user database stores user profiles. It's pretty important that it functions properly. We will try to determine what your current UserDatabase implementation is, based on the current value of the jspwiki.userdatabase property in your jspwiki.properties file. In addition, once we establish that the UserDatabase has been initialized properly, we will try to add (then, delete) a random test user. If all of these things work they way they should, then you should have no problems with user self-registration.

Good news:
  • UserDatabase is of type 'com.ecyrd.jspwiki.auth.user.XMLUserDatabase'. It appears to be initialized properly.
  • The user database contains 45 users.
  • The user database allows new users to be created, as it should.
  • The user database allows users to be deleted, as it should.
  • The user database configuration looks fine.