jforum example source code file (SecurityConfig.jsp)
The jforum SecurityConfig.jsp source code
<%@ taglib uri="/WEB-INF/jspwiki.tld" prefix="wiki" %>
<%@ page import="java.security.Principal" %>
<%@ page import="org.apache.log4j.*" %>
<%@ page import="com.ecyrd.jspwiki.*" %>
<%@ page import="com.ecyrd.jspwiki.auth.*" %>
<%@ page errorPage="/Error.jsp" %>
<%!
public void jspInit()
{
wiki = WikiEngine.getInstance( getServletConfig() );
}
Logger log = Logger.getLogger("JSPWiki");
WikiEngine wiki;
SecurityVerifier verifier;
%>
<%
WikiContext wikiContext = wiki.createContext( request, WikiContext.NONE );
if(!wikiContext.hasAccess( response )) return;
response.setContentType("text/html; charset="+wiki.getContentEncoding() );
verifier = new SecurityVerifier( wiki, wikiContext.getWikiSession() );
%>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html>
<head>
<title>JSPWiki Security Configuration Verifier
<base href="../"/>
<link rel="stylesheet" media="screen, projection" type="text/css" href="JSPWiki-container and JSPWiki-custom.
<wiki:Messages div="information" topic="<%=SecurityVerifier.INFO_JAAS%>" prefix="Good news: "/>
<wiki:Messages div="warning" topic="<%=SecurityVerifier.WARNING_JAAS%>" prefix="We found some potential problems with your configuration: "/>
<wiki:Messages div="error" topic="<%=SecurityVerifier.ERROR_JAAS%>" prefix="We found some errors with your configuration: " />
<%
if ( !verifier.isJaasConfigured() )
{
%>
<div class="error">The JAAS configuration looks broken. Users may not be able to log in. You should be able to fix this by locating the JAAS configuration file and appending the contents of WEB-INF/jspwiki.jaas.
<%
}
%>
<!--
*********************************************
**** A U T H O R I Z A T I O N ****
*********************************************
-->
<h2>Authorization Configuration
<!--
*********************************************
**** Container Authorization Verifier ****
*********************************************
-->
<h3>Container-Managed Authorization
<%
if ( isContainerAuth )
{
%>
<!-- We are using container auth -->
<p>I see that you've configured container-managed authorization. Very nice.
<%
Principal[] roles = verifier.webContainerRoles();
if ( roles.length > 0 )
{
%>
<!-- Even better, we are using the standard authorizer, which
allows us to identify the roles the container knows about -->
<p>Your WEB-INF/web.xml file defines the following roles:
<ul>
<%
for( int i = 0; i < roles.length; i++ )
{
%>
<li><%=roles[i].getName()%>
<%
}
%>
</ul>
<%
}
else
{
%>
<!-- No roles! That's very odd -->
<div class="error">Your WEB-INF/web.xml file does not define any roles. This is an error.
<%
}
}
else
{
%>
<!-- We are not using container auth -->
<p>Container-managed authorization appears to be disabled, according to your WEB-INF/web.xml file.
<%
}
%>
<!--
*********************************************
**** Java Security Policy Verifier ****
*********************************************
-->
<h3>Security Policy
<p>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.
<wiki:Messages div="information" topic="<%=SecurityVerifier.INFO+"java.security.policy"%>" prefix="Good news: "/>
<wiki:Messages div="warning" topic="<%=SecurityVerifier.WARNING+"java.security.policy"%>" prefix="We found some potential problems with your configuration: "/>
<wiki:Messages div="error" topic="<%=SecurityVerifier.ERROR+"java.security.policy"%>" prefix="We found some errors with your configuration: " />
<!-- Let the admin know if something other than JSPWiki set the policy first -->
<%
if ( verifier.isSecurityPolicyConfiguredAtStartup() )
{
%>
<div class="warning">Note: some other application set the java.security.policy system property before JSPWiki started up. It could have been done by a prior installation of JSPWiki, or possibly by your web container's startup script. This is not necessary a bad thing, but we thought you should be aware of it in case you are seeing behavior you don't expect. You can ignore this message if our policy checks are all working ok (below).
<%
}
else
{
%>
<div class="information">Note: this instance of JSPWiki set the system property at startup.
<%
}
%>
<p>Now we are going to validate the security policy file. To do this, we parse
the security policy and examine each <code>grant block. If we see
a <code>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 <code>Permission class into memory to verify that JSPWiki's classloader can find them.
<wiki:Messages div="information" topic="<%=SecurityVerifier.INFO_POLICY%>" prefix="Good news: "/>
<wiki:Messages div="warning" topic="<%=SecurityVerifier.WARNING_POLICY%>" prefix="We found some potential problems with your configuration: "/>
<wiki:Messages div="error" topic="<%=SecurityVerifier.ERROR_POLICY%>" prefix="We found some errors with your configuration: " />
<%
if ( !verifier.isSecurityPolicyConfigured() )
{
%>
<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 grant entries. The grant blocks must follow this format:
<blockquote>
<pre>grant signedBy "signer_names", codeBase "URL",
principal principal_class_name "principal_name",
principal principal_class_name "principal_name",
... {
permission permission_class_name "target_name", "action";
permission permission_class_name "target_name", "action";
};</pre>
</blockquote>
<p>Note: JSPWiki versions prior to 2.4.6 accidentally omitted commas after the signedBy entries, so you should fix this if you are using a policy file based on a version earlier than 2.4.6.
<%
}
%>
<h2>Access Control Validation
<h3>Security Policy Restrictions
<p>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.
<p>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.
<%=verifier.policyRoleTable()%>
<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.
<%
if ( isContainerAuth )
{
%>
In 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 possess the container role "Admin," for example, this will override an "edit" PagePermission granted to role "Authenticated." See below.
<%
}
%>
</div>
<%
if ( isContainerAuth )
{
%>
<h3>Web Container Restrictions
<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>The colors in each cell show the results of the test. Green means success; red means failure.
<!-- Print table showing role restrictions by JSP -->
<%=verifier.containerRoleTable()%>
<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.
<!-- Remind the admin their container needs to return the roles -->
<p>Note that your web container will allow access to these pages only if your container's authentication realm returns the roles
<%
Principal[] roles = verifier.webContainerRoles();
for( int i = 0; i < roles.length; i++ )
{
%> <strong><%=(roles[i].getName() + (i<(roles.length-1)?",":""))%><%
}
%>
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> entries in web.xml appropriately to match the role names returned by your container's authorization realm.
<p>Now we are going to compare the roles listed in your security policy with those from your web.xml 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 web.xml in blocks such as these:
<blockquote><security-role>
<description>
This logical role includes all administrative users
</description>
<role-name>Admin</role-name>
</security-role></pre>
<wiki:Messages div="information" topic="<%=SecurityVerifier.INFO_ROLES%>" prefix="Good news: "/>
<wiki:Messages div="error" topic="<%=SecurityVerifier.ERROR_ROLES%>" prefix="We found some errors with your configuration: " />
<%
}
%>
<h2>User and Group Databases
<h3>User Database Configuration
<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
Other jforum examples (source code examples)Here is a short list of links related to this jforum SecurityConfig.jsp source code file: |
The search page
Other jforum source code examples at this package level
Click here to learn more about this project
