This is version . It is not the current version, and thus it cannot be edited.
[Back to current version]   [Restore this version]

Most application servers come with a way to manage security. Authentication is by username and password. The container will return a username and can check to see if the user is in a role. The following examples will use the user.xml file:

<authenticator>
    <user name='Janne' password='dog' role='admin,superuser' />
    <user name='Foster' password='turtle' role='admin,editor' />
    <user name='Susan' password='cat' role='editor' />
    <user name='David' password='penguin' role='editor' />
</authenticator>

and part of the web.xml file:

   <security-constraint>
       <web-resource-collection>
           <web-resource-name>Protected Area</web-resource-name>
           <url-pattern>/Edit.jsp</url-pattern>
           <http-method>GET</http-method>
           <http-method>POST</http-method>
       </web-resource-collection>

       <auth-constraint>
           <role-name>admin</role-name>
           <role-name>editor</role-name>
       </auth-constraint>
   </security-constraint>
   <security-constraint>
       <web-resource-collection>
           <web-resource-name>Protected Area</web-resource-name>
           <url-pattern>/Delete.jsp</url-pattern>
           <http-method>GET</http-method>
           <http-method>POST</http-method>
       </web-resource-collection>

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

In this setup, a user must be Authenticated to use Edit.jsp and Delete.jsp. They do not need to be Authenticated to use any other url such as Wiki.jsp or Diff.jsp. Once a user is Authenticated, only users in the editor role (Foster, Susan, David) can use Edit.jsp to edit pages. To use Delete.jsp you must have the admin role (Janne and Foster). Users that try to access these pages without the proper Authorization will get back a 403 Forbidden error page.

The above setup gives unlimited view access, somewhat limited edit access and very restrictive use of delete. For most sites, this setup works as a decent control method.


Page level security#

Restricting access to a page is not possible using the basic Container Managed Security supplied with most application servers. The basic service is done on an URL basis with matching using a (very) limited regexp. The problem is that the JSPWiki URL looks like:
http://www.jspwiki.org/Wiki.jsp?page=ContainerManagedSecurity
The page is in the query string (the part after the question mark). The standard container is not able to use the query string as part of the security-constraint. If the URL was in the form of:
http://www.jspwiki.net/ContainerManagedSecurity
then basic container managed security would work[1]. To do page level security requires additional work inside the application.

The other issue with doing page level security this way is that each and every page needs to be entered into the web.xml. Which means that an administrator needs to be involved and that means payment in pints of beer or shouting a round of whiskey.

In the 2.1.x JSP Wiki there is a way to page level security that is managed by the users.

For users of the 2.0.x JSPWiki you can attempt to use the Auth Plugin to have page level security.

Both allow the user to put directives in the page to control who views and edits a page.

2.0.x: [{Auth allow='admin' deny='Janne' edit='editor' }]

2.1.x: [{ALLOW view admin}] [{DENY view Janne}] [{ALLOW edit editor}]

Both of these say Allow anyone from the Admin group look at this page, except for user Janne, and anyone from the group editor can change this page

Here are more details on the 2.1 Authorizatization setup.

See Auth Plugin for details on how that page level security can be setup using it.


[#1]But the URL does not look like that, and it's not going to look like that, so get over it.


--FosterSchucker
"Container Managed Security" doesn't mean you have to use declarative security for everything. Although, it means that you use standard J2EE APIs for doing programmatic security when not doing declarative security. Just because you can't declare security for Wiki pages doesn't mean you have to abandon J2EE security altogether. You could programmatically enforce wiki page authorization using Container Managed authentication (users/roles).
At my site, I have container managed security for access to basic functions like edit and delete. The standard J2EE API is used, when I log in, the container does the Authentication. It returns to JSPWiki my user information (remoteUser). Since the Wiki does not know about roles it does everything on a user basis. So when I login JSPWiki knows that I'm FosterSchucker, but does not care that I'm part of role editor. So I am using, and JSPWiki can use Container Managed Security at a high level.

It becomes sticky when you try to control access to a WikiPage for:

  • Page view
  • Partial page view (Page A is included inside Page B)
  • Indirect page view (LeftMenu is a good example)
  • Page edit
  • Page status (the More Information link)
  • Page differences

ContainerManagedSecurityDiscussion

Add new attachment

Only authorized users are allowed to upload new attachments.
« This particular version was published on 24-Mar-2004 19:06 by FosterSchucker.