1<%@ taglib uri="/WEB-INF/jspwiki.tld" prefix="wiki" %> 2<%@ page import="java.security.Principal" %> 3<%@ page import="org.apache.log4j.*" %> 4<%@ page import="com.ecyrd.jspwiki.*" %> 5<%@ page import="com.ecyrd.jspwiki.auth.*" %> 6<%@ page errorPage="/Error.jsp" %> 7<%! 8 public void jspInit() 9 { 10 wiki = WikiEngine.getInstance( getServletConfig() ); 11 } 12 Logger log = Logger.getLogger("JSPWiki"); 13 WikiEngine wiki; 14 SecurityVerifier verifier; 15%> 16<% 17 WikiContext wikiContext = wiki.createContext( request, WikiContext.NONE ); 18 if(!wikiContext.hasAccess( response )) return; 19 response.setContentType("text/html; charset="+wiki.getContentEncoding() ); 20 verifier = new SecurityVerifier( wiki, wikiContext.getWikiSession() ); 21 22 // 23 // This is a security feature, so we will turn it off unless the 24 // user really wants to. 25 // 26 if( !TextUtil.isPositive(wiki.getWikiProperties().getProperty("jspwiki-x.securityconfig.enable")) ) 27 { 28 %> 29 <html> 30 <head> 31 <base href="../"/> 32 <link rel="stylesheet" media="screen, projection" type="text/css" href="<wiki:Link format="url" templatefile="jspwiki.css"/>"/> 33 <wiki:IncludeResources type="stylesheet"/> 34 </head> 35 <body><div id="wikibody"> 36 <h1>Disabled</h1> 37 <p>JSPWiki SecurityConfig UI has been disabled. This page could reveal important security 38 details about your configuration to a potential attacker, so it has been turned off by 39 default. However, it is very easy to enable it by setting the following value</p> 40 <pre> 41 jspwiki-x.securityconfig.enable=true 42 </pre> 43 <p>in your <tt>jspwiki.properties</tt> file.</p> 44 <p>Once you are done with debugging your security configuration, please turn this page 45 off again by removing the preceding line, so that your system is safe again.</p> 46 <p>Have a nice day. May the Force be with you.</p> 47 </div></body> 48 </html> 49 <% 50 return; 51 } 52 53%> 54<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" 55 "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> 56<html xmlns="http://www.w3.org/1999/xhtml"> 57<head> 58 <title>JSPWiki Security Configuration Verifier</title> 59 <base href="../"/> 60 <link rel="stylesheet" media="screen, projection" type="text/css" href="<wiki:Link format="url" templatefile="jspwiki.css"/>"/> 61 <wiki:IncludeResources type="stylesheet"/> 62</head> 63<body> 64<div id="wikibody"> 65<div id="page"> 66<div id="pagecontent"> 67 68<h1>JSPWiki Security Configuration Verifier</h1> 69 70<p>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.</p> 71 72<p>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.</p> 73 74<p><strong>Please delete this JSP when you are finished troubleshooting your system. 75This diagnostic data presented on this page do not represent a security risk 76to your system <em>per se</em>, but they do provide a significant amount of 77contextual information that could be useful to an attacker. This page is 78currently unconstrained, which means that anyone can view it: nice people, mean people 79and everyone in between. You have been warned. You can turn it off by setting 80<pre> 81 jspwiki-x.securityconfig.enable=false 82</pre> 83in your jspwiki.properties. 84</strong></p> 85 86<!-- 87 ********************************************* 88 **** A U T H E N T I C A T I O N **** 89 ********************************************* 90--> 91<h2>Authentication Configuration</h2> 92<!-- 93 ********************************************* 94 **** Container Authentication Verifier **** 95 ********************************************* 96--> 97<h3>Container-Managed Authentication</h3> 98<% 99 boolean isContainerAuth = wiki.getAuthenticationManager().isContainerAuthenticated(); 100 AuthorizationManager authorizationManager = wiki.getAuthorizationManager(); 101 if ( isContainerAuth ) 102 { 103%> 104 <!-- We are using container auth --> 105 <p>I see that you've configured container-managed authentication. Very nice.</p> 106<% 107 } 108 else 109 { 110%> 111 <!-- We are not using container auth --> 112 <p>Container-managed authentication appears to be disabled, according to your <code>WEB-INF/web.xml</code> file.</p> 113<% 114 } 115%> 116 117 118<!-- 119 ********************************************* 120 **** JAAS Authentication Config Verifier **** 121 ********************************************* 122--> 123<h3>JAAS Login Configuration</h3> 124 125<!-- Notify users which JAAS configs we need to find --> 126<p>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 <code>jspwiki.loginModule.class</code> property in <code>jspwiki.properties</code>.</p> 127 128<wiki:Messages div="information" topic='<%=SecurityVerifier.INFO+"java.security.auth.login.config"%>' prefix="Good news: "/> 129<wiki:Messages div="warning" topic='<%=SecurityVerifier.WARNING+"java.security.auth.login.config"%>' prefix="We found some potential problems with your configuration: "/> 130<wiki:Messages div="error" topic='<%=SecurityVerifier.ERROR+"java.security.auth.login.config"%>' prefix="We found some errors with your configuration: " /> 131 132<!-- Print JAAS configuration status --> 133<p>The JAAS login configuration is correctly configured if the <code>jspwiki.loginModule.class</code> property specifies 134a class we can find on the classpath. This class must also be a LoginModule implementation. We will check for both conditions.</p> 135 136<wiki:Messages div="information" topic="<%=SecurityVerifier.INFO_JAAS%>" prefix="Good news: "/> 137<wiki:Messages div="warning" topic="<%=SecurityVerifier.WARNING_JAAS%>" prefix="We found some potential problems with your configuration: "/> 138<wiki:Messages div="error" topic="<%=SecurityVerifier.ERROR_JAAS%>" prefix="We found some errors with your configuration: " /> 139 140<!-- 141 ********************************************* 142 **** A U T H O R I Z A T I O N **** 143 ********************************************* 144--> 145<h2>Authorization Configuration</h2> 146 147<!-- 148 ********************************************* 149 **** Container Authorization Verifier **** 150 ********************************************* 151--> 152<h3>Container-Managed Authorization</h3> 153<% 154 if ( isContainerAuth ) 155 { 156%> 157 <!-- We are using container auth --> 158 <p>I see that you've configured container-managed authorization. Very nice.</p> 159<% 160 Principal[] roles = verifier.webContainerRoles(); 161 if ( roles.length > 0 ) 162 { 163%> 164 <!-- Even better, we are using the standard authorizer, which 165 allows us to identify the roles the container knows about --> 166 <p>Your <code>WEB-INF/web.xml</code> file defines the following roles:</p> 167 <ul> 168<% 169 for( int i = 0; i < roles.length; i++ ) 170 { 171%> 172 <li><%=roles[i].getName()%></li> 173<% 174 } 175%> 176 </ul> 177<% 178 } 179 else 180 { 181%> 182 <!-- No roles! That's very odd --> 183 <div class="error">Your <code>WEB-INF/web.xml</code> file does not define any roles. This is an error.</div> 184<% 185 } 186 } 187 else 188 { 189%> 190 <!-- We are not using container auth --> 191 <p>Container-managed authorization appears to be disabled, according to your <code>WEB-INF/web.xml</code> file.</p> 192<% 193 } 194%> 195 196<!-- 197 ********************************************* 198 **** Java Security Policy Verifier **** 199 ********************************************* 200--> 201<h3>Security Policy</h3> 202<p>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.</p> 203 204<p>Let's validate the local security policy file. To do this, we parse 205the security policy and examine each <code>grant</code> block. If we see 206a <code>permission</code> entry that is signed, we verify that the certificate 207alias exists in our keystore. The keystore itself must also exist in the file system. 208And as an additional check, we will try to load each <code>Permission</code> class into memory to verify that JSPWiki's classloader can find them.</p> 209 210<wiki:Messages div="information" topic="<%=SecurityVerifier.INFO_POLICY%>" prefix="Good news: "/> 211<wiki:Messages div="warning" topic="<%=SecurityVerifier.WARNING_POLICY%>" prefix="We found some potential problems with your configuration: "/> 212<wiki:Messages div="error" topic="<%=SecurityVerifier.ERROR_POLICY%>" prefix="We found some errors with your configuration: " /> 213 214<% 215 if ( !verifier.isSecurityPolicyConfigured() ) 216 { 217%> 218 <p>Note: JSPWiki's Policy file parser is stricter than the default parser that ships with the JVM. If you encounter parsing errors, make sure you have the correct comma and semicolon delimiters in your policy file <code>grant</code> entries. The <code>grant</code> blocks must follow this format:</p> 219 <blockquote> 220 <pre>grant signedBy "signer_names", codeBase "URL", 221 principal principal_class_name "principal_name", 222 principal principal_class_name "principal_name", 223 ... { 224 225 permission permission_class_name "target_name", "action"; 226 permission permission_class_name "target_name", "action"; 227};</pre> 228 </blockquote> 229 230 <p>Note: JSPWiki versions prior to 2.4.6 accidentally omitted commas after the <code>signedBy</code> entries, so you should fix this if you are using a policy file based on a version earlier than 2.4.6.</p> 231<% 232 } 233%> 234 235<h2>Access Control Validation</h2> 236 237<h3>Security Policy Restrictions</h3> 238 239<p>Now comes the <em>really</em> 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.</p> 240 241<p>The colors in each cell show the results of the test. <font style="background-color: #c0ffc0;"> Green </font> means success; <font style="background-color: #ffc0c0;"> red </font> means failure. Hovering over a role name or individual cell will display more detailed information about the role or test.</p> 242 243<%=verifier.policyRoleTable()%> 244 245<div class="information">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. 246<% 247 if ( isContainerAuth ) 248 { 249%> 250In addition, because you are using container-managed security, constraints on user activities might be stricter than what is shown in this table. If the container requires that users accessing <code>Edit.jsp</code> possess the container role "Admin," for example, this will override an "edit" PagePermission granted to role "Authenticated." See below. 251<% 252 } 253%> 254</div> 255 256<% 257 if ( isContainerAuth ) 258 { 259%> 260 <h3>Web Container Restrictions</h3> 261 262 <p>Here is how your web container will control role-based access to some common JSPWiki actions and their assocated JSPs. These restrictions will be enforced even if your Java security policy is more permissive.</p> 263 264 <p>The colors in each cell show the results of the test. <font style="background-color: #c0ffc0;"> Green </font> means success; <font style="background-color: #ffc0c0;"> red </font> means failure.</p> 265 266 <!-- Print table showing role restrictions by JSP --> 267 <%=verifier.containerRoleTable()%> 268 269 <div class="information">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.</div> 270 271 <!-- Remind the admin their container needs to return the roles --> 272 <p>Note that your web container will allow access to these pages <em>only</em> if your container's authentication realm returns the roles 273<% 274 Principal[] roles = verifier.webContainerRoles(); 275 for( int i = 0; i < roles.length; i++ ) 276 { 277%> <strong><%=(roles[i].getName() + (i<(roles.length-1)?",":""))%></strong><% 278 } 279%> 280 If your container's realm returns other role names, users won't be able to access the pages they should be allowed to see -- because the role names don't match. In that case, You should adjust the <code><role-name></code> entries in <code>web.xml</code> appropriately to match the role names returned by your container's authorization realm.</p> 281 282 <p>Now we are going to compare the roles listed in your security policy with those from your <code>web.xml</code> file. The ones we care about are those that aren't built-in roles like "All", "Anonymous", "Authenticated" or "Asserted". If your policy shows roles other than these, we need to make sure your container knows about them, too. Container roles are defined in <code>web.xml</code> in blocks such as these:</p> 283 <blockquote><pre><security-role> 284 <description> 285 This logical role includes all administrative users 286 </description> 287 <role-name>Admin</role-name> 288</security-role></pre></blockquote> 289 290 <wiki:Messages div="information" topic="<%=SecurityVerifier.INFO_ROLES%>" prefix="Good news: "/> 291 <wiki:Messages div="error" topic="<%=SecurityVerifier.ERROR_ROLES%>" prefix="We found some errors with your configuration: " /> 292 293<% 294 } 295%> 296 297<h2>User and Group Databases</h2> 298 299<h3>User Database Configuration</h3> 300<p>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 <code>jspwiki.userdatabase</code> property in your <code>jspwiki.properties</code> 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.</p> 301 302<wiki:Messages div="information" topic="<%=SecurityVerifier.INFO_DB%>" prefix="Good news: "/> 303<wiki:Messages div="warning" topic="<%=SecurityVerifier.WARNING_DB%>" prefix="We found some potential problems with your configuration: "/> 304<wiki:Messages div="error" topic="<%=SecurityVerifier.ERROR_DB%>" prefix="We found some errors with your configuration: " /> 305 306<h3>Group Database Configuration</h3> 307<p>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 <code>jspwiki.groupdatabase</code> property in your <code>jspwiki.properties</code> 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.</p> 308 309<wiki:Messages div="information" topic="<%=SecurityVerifier.INFO_GROUPS%>" prefix="Good news: "/> 310<wiki:Messages div="warning" topic="<%=SecurityVerifier.WARNING_GROUPS%>" prefix="We found some potential problems with your configuration: "/> 311<wiki:Messages div="error" topic="<%=SecurityVerifier.ERROR_GROUPS%>" prefix="We found some errors with your configuration: " /> 312 313<!-- We're done... --> 314</div> 315</div> 316</div> 317</body> 318</html> 319