HyperContent 2 is set up to accommodate any user who successfully authenticates into the system. HC2 uses JAAS LoginModules to perform authentication; the built-in module validates against an MD-5 hash of the user"s password in a user file. A CAS/JAAS module is included with the distribution.

Read, write, create, delete, build, publish & approve permissions can all be controlled on a per-project basis in the file "/config/permissions.xml". The model is very similar to uPortal's Groups and Permissions. Each permissions has 4 components:

Principal

• the user or group name that the permission applies to (by convention, group names in HC2 are prefixed with "group:" to avoid name collisions with users)

Activity

• read, write, create, delete, build, publish or approve (custom activities can be used in controlling workflows)

Target

• The pattern of files or directories to which the permission applies
• /**/*.* = all files
• /**/ = all directories
• /students/*.xml = all XML files in the students directory
• /students/**/*.* = all files in the students directory or recursively any of its subdirectories
• /index.xml = the home page

Denied

• if true, indicates that this is a negating permission

When multiple permissions match a given file or directory for a given user, the permission with the most specific pattern is applied, e.g. given

Denied="false" target="/students/**/*.*"
Denied="true" target="/students/**/sensitive/*.*"

Access to any file in a directory named "sensitive" below the students directory will be blocked.

Groups are specified per-project in "/config/groups.xml". Each group is assigned a name, and can have any number of group or user sub-elements. There are two special group names: "group:anybody" applies to any user session, even if unauthenticated, allowing world-read privileges to be established. "group:admin" is used to configure superusers, who are automatically granted all permissions. User IDs configured in group:admin in the bootstrap project are superusers across all projects, whereas users listed in group:admin in a project"s groups file are superusers for that project only.

Examples

<!-- group declarations can be nested, so that the contained groups will
     inherit the permissions of the containing group -->

<group name="group:authors">
    <group name="group:section1-authors">
        <user name="id1"/>
        <group name="group:section1-approvers">
            <user name="id2"/>
        </group>
    </group>
    <group name="group:section2-authors">
        <user name="id3"/>
        <group name="group:section2-approvers">
            <user name="id4"/>
        </group>
    </group>
</group>

<!-- members of group:admin are automatically granted all permissions on every
     file, directory and workflow script throughout the project -->

<group name="group:admin">
    <user name="id5"/>
</group>



<!-- group:anybody includes all users, including non-authenticated sessions.
     this allows anyone to read any file in the repository, except for those 
     denied by more specific permissions -->
     
<permission principal="group:anybody" target="/**/*.*" activity="read"/>

<!-- read permission is required on a directory to list its contents or to see
     it listed in its parent directory -->
     
<permission principal="group:anybody" target="/**/" activity="read"/>

<!-- deny everyone from seeing configuration or workflow files or the
     directories that contain them.  More specific groups may be used
     to enable read permission for these files for a limited set of users,
     or may be left accessibly only to members of "group:admin"  -->
     
<permission principal="group:anybody" target="/config/**/*.*" activity="read" denied="true"/>
<permission principal="group:anybody" target="/config/**/" activity="read" denied="true"/>
<permission principal="group:anybody" target="/workflow-data/**/*.*" activity="read" denied="true"/>
<permission principal="group:anybody" target="/workflow-data/**/" activity="read" denied="true"/>

<!-- give all authors permission to see workflow files -->

<permission principal="group:authors" target="/workflow-data/**/*.*" activity="read"/>

<!-- give section 1 authors the appropriate create, write and delete permissions -->

<permission principal="group:section1-authors" target="/section1/**/*.*" activity="create"/>
<permission principal="group:section1-authors" target="/section1/**/*.*" activity="write"/>
<permission principal="group:section1-authors" target="/section1/**/*.*" activity="delete"/>

<!-- section 1 approvers inherit create, write and delete from authors: they just need approval -->

<permission principal="group:section1-approvers" target="/section1/**/*.*" activity="approve"/>

<!-- and repeat for section 2 -->

<permission principal="group:section2-authors" target="/section2/**/*.*" activity="create"/>
<permission principal="group:section2-authors" target="/section2/**/*.*" activity="write"/>
<permission principal="group:section2-authors" target="/section2/**/*.*" activity="delete"/>
<permission principal="group:section2-approvers" target="/section2/**/*.*" activity="approve"/>