Page History

Security in Islandora is the result of combining Drupal's Drupal’s Acess Control infrastructure (Drupal Roles and Permissions) with Fedora's Fedora’s security framework. Fedora's Fedora’s framework offers a great deal of flexibility and customization. Additional information about Fedora security is available at the FedoraCommons wiki (see our Selected Reading Section). This section will cover the basics of Drupal security, and describe the way that Islandora allows for Fedora security to interact with Drupal security.

...

In a Drupal site, you can allow (or prevent) people from doing things like creating accounts, or viewing your site by navigating to administer > user management > user settings. Drupal also gives you the ability to divide your site users into different groups, by creating "Roles" “Roles” for users. A "Role" “Role” defines who your user is, and what they should be able to access, update, delete, or create in a Drupal site.

Drupal 6 comes out-of-the-box with two roles (in addition to administrators, who have all permissions). These roles are anonymous user (somebody without an account) and authenticated user (somebody with an account, that logs in to the site). Administrators can create new Roles under the "User Management" “User Management” section of Drupal's Drupal’s administration pages.

Under "User Management" in Drupal's “User Management” in Drupal’s administration screen you can access "permissions“permissions." ” Drupal describes permissions as "granted" “granted” to separate roles. Any module installed will generally make additional types of permissions available. Islandora is no different from other modules, and in order to effectively use Islandora, you will want to "grant" “grant” permissions to roles.  Users are assigned roles and can have multiple, with the user possessing all the permissions that their various roles do.  Here are the permissions that the Islandora module makes available: 

...

• If you allow a role to add fedora datastreams, users with that role will be able to add a datastream to an object in your repository (presuming the content model affiliated with that object has defined the datastream being added as part of the content model).
• If you allow a role to create batch process, users with that role will be able to upload tar files for ingest.
• If you allow a role to delete entire collections, users with that role will be able to purge entire collections (the collection object and all members) without iterating over all the member objects manually.
• If you allow a role to edit fedora metadata, users with that role will be able to edit the metadata record for any object.
• If you allow a role to edit tags datastream, this functionality appears incomplete.
• If you allow a role to ingest new Fedora objects, users with that role will be able to add items into the repository.
• If you allow a role to manage collections, users with that role will have access to some collection level utilities, such as changing the allowed content models.
• If you allow a role to purge objects and datastreams, users with that role will be able to purge objects, and replace and purge datastreams in an objects.
• If you allow a role to view detailed list of content, users with that role will be able to view the datastream details of a given object (available under the "detailed “detailed list of content" content” fieldset in any object view)
• If you allow a role to view fedora collection, users with that role will be able to view your collections

...

When you are using Islandora, Fedora's Fedora’s entire suite of security features are available to you. Fedora security starts with your repository setup, but can be refined further using object-specific XACML policies (written in eXtensible Access Control Markup Language). XACML is both an access control policy language implemented in XML and a processing model that describes how to interpret the policies. In order to use XACML, you need to have enforced policies in your Fedora configuration file (fedora.fcfg).

...