RE: : Are default Domail.xml/web.xml roles consistent?

[Peter Hawkins <pe...@globalvision.com.au>]

Let me see if I can clarify a little...

The first thing to note is what the difference is between Domain.xml and
web.xml. Essentially they configure different things. Slide consists of a
java managed bean (the core) which does most of the work and also comes with
two servlets (Slide and Manager) which are layers above the bean. The Slide
servlet is an interface to the bean and is in turn driven by a "servlet
container" such as Tomcat.

Think of a servlet as a "little server". Imagine setting up a whole lot of
dedicated webservers that specialise in some particular job. You might have
a servlet to serve web pages, but another is a program that reads email.
With Apache, you'd do this with one huge web server, a series of Virtual
Hosts and some CGIs. Servlets are simply dedicated servers for a single
given task and are usually programs (such as an IMAP to HTTP program instead
of a PHP IMAP script running in the same server as everything else).

However it is not neccessary to use the servlet to use slide. You could
interface directly to the slide API and build your own system using slide's
core (DAV) functionality, it's data storage systems etc. In this case you
would _still_ need a Domain.xml file to configure the "domain" (the way data
is layed out, permissions, user passwords etc), but would probably not use
the supplied web.xml. It governs security within the domain - who can do
what to what nodes within the hierarchy, who is given which "role" etc.

Web.xml (a "deployment descriptor" is something you need whenever you deploy
a servlet (any servlet) and configures the servlet - it is somewhat like a
<VirtualHost> section in apache httpd.conf file.  It typically lists things
like the welcom (index) file names, directory permissions etc. See chapters
9, 10 and 11 of the java servlet spec available from
http://java.sun.com/products/servlet/ for more information about web.xml
files.

As you can see, these two files have to be set up for a proper security
configuration.



1) The Domain.xml configuration file currently contains the following roles
definitions

      <!-- Roles definition -->
      <role name="admin">slideroles.basic.RootRole</role>
      <role name="user">slideroles.basic.UserRole</role>
      <role name="guest">slideroles.basic.GuestRole</role>

This section is a declaration - simply a list of the _roles_ to be used for
the domain. It associates a "name" (login ID) with a role as recognised by
slide such as slideroles.basic.RootRole. As you can see, we identify a role
by naming its class. The classes for roles (such as
slideroles.basic.RootRole) live in the

   src\roles\slideroles\basic\

directory and they're essentially almost-vanilla subjectNode classes.

Anyway the above section says "if someone logs in with username "admin",
associate them with the class slideroles.basic.RootRole (and so on).

Of course, if you have decided to have your authentication done by the
servlet container (tomcat and you are not using SlideRealm, say), the roles
are assigned by the container (eg tomcat-users.xml). In that case the
Roles-definition above is not used. On the other hand, if you configure
tomcat with SlideRealm, tomcat will refer user identification to slide and
slide will use the Domain.xml configuration file to do that.

2) Later in Domain.xml we see

        <!-- /users represents the unauthenticated user -->

        <objectnode classname="org.apache.slide.structure.SubjectNode"
uri="/users">
          <permission action="/actions" subject="~"/>
          <permission action="/actions" subject="guest" inheritable="true"
negative="true"/>
          <permission action="/actions/read" subject="user"
inheritable="false"/>

        [SNIP - permissions group example here]

          <!-- /users/root represents the administrator -->
          <objectnode classname="slideroles.basic.RootRoleImpl"
uri="/users/root">
            <revision>
              <property name="password">root</property>
            </revision>
          </objectnode>

        [SNIP - similar definitions for the other two roles here]
        </objectnode>

Which configures rights for the subjectnode (or "directory" in this case)
"/users".

The <permissions> tags enable users with the given roles to apply items from
the "/actions" node (which includes read, write etc). For example the role
"guest" has _negative_ access to /actions and this is inherited by any node
beneath this thus denying guest access to /users/*. However an authenticated
user (role "user") can access /actions/read in uri /users, however this
right is not automatically inherited, so that fred can read the /users
contents, but not /users/jane (by default). However the first <permission>
tag gives a user access to all actions when in their own area.

The second block above defines a property for the administrator
(password=root, though this is only used when authenticating with SlideRealm
rather instead of using tomcat.users). The node is identified both by it's
role class (slideroles.basic.RootRoleImpl) and uri (/users/root).

If your authentication is being done by tomcat-users.xml, the second block
here is not used as the passwords are defined in tomcat-users.xml, however
the first block (<permission ...> section) is still used to configure access
rights to the nodes in a domain.


3 The security constraint section of web.xml looks like this

   <!--security-constraint>
     <web-resource-collection>
       <web-resource-name>DAV resource</web-resource-name>
       <url-pattern>/*</url-pattern>
       <http-method>COPY</http-method>
       [SNIP - other methods here]
      </web-resource-collection>
     <auth-constraint>
       <role-name>root</role-name>
       <role-name>guest</role-name>
     </auth-constraint>
   </security-constraint>

   <security-constraint>
     <web-resource-collection>
       <web-resource-name>Manager</web-resource-name>
       <url-pattern>/manager/*</url-pattern>
       <http-method>GET</http-method>
       <http-method>POST</http-method>
     </web-resource-collection>
     <auth-constraint>
       <role-name>root</role-name>
     </auth-constraint>
   </security-constraint>

And (as you can see) is commented out (!-- ....). The first thing to do is
remove the !-- and the --> which you'l find later in the file.

When you uncomment the section, the servlet will serve requests to
appropriate people. Look at the second section first as it is perhaps more
familiar to most people. It tells the manager servlet to serve GET and POST
requests from someone whose role is "root". In fact it says that a request
for (say)   www.myserver.com.au/manager/index.html [post request] or
www.myserver.com.au/manager/index.html?index=1 [a get request] is acceptable
if you're logged in as a user that has role root.

Now, HTTP requests are almost always GET and PUT (though there are actually
a few others that are rarely used). WebDAV adds a whole lot more types of
requests. A WebDAV-aware "browser" can send a COPY request (for example) and
the first of the two blocks above allows this to be served to root and guest
users for (say) www.myserver.com.au/index.html


Hope this helps!
Peter