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
currently unconstrained, which means that anyone can view it: nice people, mean people
and everyone in between. You have been warned. You can turn it off by setting
jspwiki-x.securityconfig.enable=false
in your jspwiki.properties.
Container-managed authentication appears to be disabled, according to your WEB-INF/web.xml file.
JSPWiki wires up its own JAAS to define the authentication process,
and does not rely on the JRE configuration. By default, JSPWiki
configures its JAAS login stack to use the UserDatabaseLoginModule. You
can specify a custom login module by setting the jspwiki.loginModule.class property in jspwiki.properties.
The JAAS login configuration is correctly configured if the jspwiki.loginModule.class property specifies
a class we can find on the classpath. This class must also be a LoginModule implementation. We will check for both conditions.
Container-managed authorization appears to be disabled, according to your WEB-INF/web.xml file.
JSPWiki's authorizes user actions by consulting a standard Java 2 security policy file. By default, JSPWiki installs its local security policy file at startup time. This policy file is independent of your global, JVM-wide security policy, if you have one. When checking for authorization, JSPWiki consults the global policy first, then the local policy.
Let's validate the local 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.
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 | JSPWikiAuthenticated | JSPWikiAdmin | ||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 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 "Scharnhorst-wiki:Main" | ||||||||||||||||||||||||||||||
| PagePermission "Scharnhorst-wiki:Index" | ||||||||||||||||||||||||||||||
| PagePermission "Scharnhorst-wiki:GroupTest" | ||||||||||||||||||||||||||||||
| PagePermission "Scharnhorst-wiki:GroupAdmin" | ||||||||||||||||||||||||||||||
| GroupPermission "Scharnhorst-wiki:Admin" | ||||||||||||||||||||||||||||||
| GroupPermission "Scharnhorst-wiki:TestGroup" | ||||||||||||||||||||||||||||||
| GroupPermission "Scharnhorst-wiki:Foo" | ||||||||||||||||||||||||||||||
| WikiPermission "Scharnhorst-wiki","createGroups" | ||||||||||||||||||||||||||||||
| WikiPermission "Scharnhorst-wiki","createPages" | ||||||||||||||||||||||||||||||
| WikiPermission "Scharnhorst-wiki","login" | ||||||||||||||||||||||||||||||
| WikiPermission "Scharnhorst-wiki","editPreferences" | ||||||||||||||||||||||||||||||
| WikiPermission "Scharnhorst-wiki","editProfile" | ||||||||||||||||||||||||||||||
| AllPermission "Scharnhorst-wiki" | ||||||||||||||||||||||||||||||
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.
The group database stores wiki groups. It's pretty important that it
functions properly. We will try to determine what your current
GroupDatabase implementation is, based on the current value of the jspwiki.groupdatabase property in your jspwiki.properties
file. In addition, once we establish that the GroupDatabase has been
initialized properly, we will try to add (then, delete) a random test
group. If all of these things work they way they should, then you
should have no problems with wiki group creation and editing.