Our exploration into security for Greenstone 3 using the built-in security provided by the Java Servlet API has gone well. We now have the ability to allow users to restrict parts of their collections to users within certain groups by specifying constraints in the collectionConfig.xml file. We are still working on the exact format for the XML but here is an example of a set of constraints in the current format:

<security scope="documents" default_access="public">
  <documentSet name="firstSet">
    <match>HASHe08571b7f6e430e238e2dd</match>
    <match field="Title" type="regex">.* Garden</match>
  </documentSet>
  <documentSet name="secondSet">
    <match field="Title" type="regex">Egyptian .*</match>
  </documentSet>
  <exception>
    <documentSet name="firstSet"/>
    <group name="dl"/>
  </exception>
  <exception>
    <documentSet name="secondSet"/>
    <group name="administrator"/>
  </exception>
</security>


You’ll notice that in the <security> element there are two attributes. The default_access attribute can be either “public” or “private” and this specifies whether the normal (guest) user can access the collection/documents. The scope attribute can be either “collection” or “documents” and this specifies whether these rules affect the whole collection or a set of documents. An average collection will have a very simple security block like:

<security scope="collection" default_access="public"/>

which specifies that the whole collection is publicly accessible. As you can see with the first example, we also allow much more detailed control over what documents each group can access. What this example specifies is that the average user can access the majority of the documents with a few exceptions. In order to access the “firstSet” set of documents (which contains the document with the ID  HASHe08571b7f6e430e238e2dd and all documents whose titles end in “Garden”) you have to be in the “dl” group. In order to access the”secondSet” set of documents (which contains documents whose titles start with “Egyptian”) you have to be an administrator.

As well as working on security I have made various improvements to the document editor. Users can now edit documents directly on the document page, which allows users to very efficiently perform any basic (content and metadata) modifications. The previous document editor is still where more advanced edits (structure, document creation/deletion) can be performed.

Things have been fairly busy here the last few weeks so I’ve been a little slack on the blogging. We have been continuing to look into robust authentication for Greenstone 3 and as part of the we have been investigating the security features that the Java Servlet technology (that Greenstone 3 uses) has built in. We have also been devising a way to specify the security settings that you want – like in Greenstone 2 – but in a way that is more flexible. For example, we are looking into the idea of groups of users (e.g. admin, staff, students etc.) that can have access to different documents based on the groups they are in.

I’ll write more details on this next week.