You can define access control settings under the "Edit -> Access" menu for an entry.

Image 1: Entry Access Control

The access control mechanism in RAMADDA is centered around a set of actions (e.g., viewing, new, edit) and a set of user roles that have permissions to do those actions. On the left of this form lists each of the actions. For each action there is a field where you can enter any number of user roles (one per line). On the right shows a summary table for the particular entry we are viewing. This shows the access control settings for all of the ancestor folders of the entry and allows the user to see just what access settings are applicable to the entry.

To see if a given user has the ability to do a particular action for a particular entry RAMADDA looks at the permissions for the entry.

• If there are no permissions defined then the parent entry is recursively checked.
• If the user matches one of the roles then permission is granted.
• If there is a specific denial of permission (e.g, "none") then permission is not granted.
• If nothing matches then, by default, permission is not granted. However, the permissions of the parent are checked if there is a special role "inherit" defined. Also, if the RAMADDA repository has the property ramadda.auth.stopatfirstrole=false set to false then the parent is always checked.
• This process continues to the top most entry which has a set of default permissions.

In the example shown above any user in the role "group1" can view anything under the Parent Folder. No other user can view the Parent Folder because of the "none" specified. Along with the view access, the user "joe" can also edit the Parent Folder and any entry under the Parent Folder.

Here are other examples:

• To make a whole tree of entrys inaccessable - under the view action enter:
  none
• If you wanted to give a certain user permission (e.g., joe) to view the entry but not allow any one else to view then enter under the view action:
  user:joe
  none
  RAMADDA would first check if the given user was "joe". If it is "joe" then permission is granted. If its not "joe" then RAMADDA looks at the next role - "none". This blocks any other access.
  Note: If you did not specify "none" here then permission would still be denied unless the ramadda.auth.stopatfirstrole=false property has been set for the entire repository.
• To allow for a group of users in the role "group1" to be able to edit and create new entries under a whole tree then enter:
  group1
  for both the edit and the new actions.
• A common case is to allow one role to have new and edit capabilities under a whole tree (like the group1 example above) but to grant new and edit capabilities to some other user to a sub tree. For this you would grant the access to the parent entry like above, e.g.:
  • parent entry - access =
    group1
    • ...
      • descendent entry - access =
        otheruser
        inherit
  Because the descendent entry has "inherit" defined then the parent entry is checked.

Each access type can contain any number of roles (one per line).

• Special roles
  • any - this is a special role and says that anyone can do the action.
  • none - nobody (except admins) can do the action.
  • user - any logged in user
  • anonymous - the user is not logged in
  • guest - the user is a guest user
• Assigned user roles - All users can have one or more roles. This is set by the site administrator when editing the user. They are just string names. For example, you might have the roles "group1" and "group2". If you wanted to grant access to "group1" you would just enter:
  group1
  If you wanted to grant access to users in either group1 or group2 you would enter:
  group1
  group2
• Self identity role - If you enter a role in the form as user:someuserid this grants access to that specific user. So, if you wanted to give "joe" access to something enter:
  user:joe
• ip:ip address - This format grants access to incoming requests with the given ip address or ip address suffix. For example, the following would grant access to any request coming from any IP address that starts with 128.117
  ip:128.117
• !some role - Prefixing a role with "!" is a way to deny specific access to a user, role, or ip address. For example, the following would deny access to any request coming from any IP address that starts with 128.117:
  !ip:128.117
  Say you want to grant access to user "joe" but deny access to user "jim". You would do:
  user:joe
  !user:jim

The different access types are:

• View - Can a user view the entry. If a user does not have view access they will simply not see the entry and cannot access any aspect of the entry.
• View Children - This is used for a folder where a user without permission can see that the folder exists (e.g., "Unidata Only") but cannot see any of the details of the folder or any of the children entry of the folder.
• File - This allows users to see the information about an entry but they cannot access the file. i.e., they cannot download the file or access any of the content of the file (e.g., through OpenDAP).
• Edit - Can a user edit the entry.
• New - Can a user create a new sub-folder or sub-entry. Note: when users have this permission they also need Edit permission.
• Upload - This provides anonymous upload capability. For example, we use this to provide an area for IDV users to upload shared content. When a file is uploaded it is marked so that only administrators or owners of the Folder can access it. The owner of the folder will receive an email (if email is configured) notifying them of the uploaded file. In the Edit page for the uploaded Entry the owner can "bless" the entry to make it available to others.

  If you want more people than the owner to receive notification simply add a "Contact" property to the folder that contains the other recipient's email.

• Delete - Can a user delete an entry.
• Comment - Can a user comment on an entry.