Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

Security in Islandora leverages both Drupal’s Access Control infrastructure (Drupal Roles and Permissions) with Fedora’s XACML security framework to create a highly flexible framework that can write restrictions to the datastream and IP level. Additional information about Fedora security is available at the FedoraCommons wiki (see our Selected Reading Section). Note that Fedora's permissions restrictions are always enforced over Drupal's, but Fedora XACML policies cannot grant a user access that they do not have via Drupal permissions

Drupal Security and Islandora

...

In the Islandora configuration pane. (admin/islandora/configure) under "namespaces," an administrator can set a Drupal site to only allow access to specific namespaces. This is particularly useful in multisite configurations. 

Permissions and Roles

 Drupal Drupal gives you the ability to divide your site users into different groups, by creating “Roles” for users. A “Role” defines who your user is, and what they should be able to access, update, delete, or create in a Drupal site. Roles are managed at admin/people/permissions/roles. Drupal 7 comes out-of-the-box with an administrative role, an anonymous user role (somebody without an account) and an authenticated user role (somebody with an account, that logs in to the site). Additional roles can be created and then assigned permissions at admin/people/permissions.

...

Islandora uses the XACML framework in FedoraCommons. XACML (written in eXtensible Access Control Markup Language) is  as 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). XACML policies are first applied when your repository is set up, and these permissions would be managed by the person installing and maintaining Islandora. 

These initial policies are always enforced. No object-specific XACML policy can ever override a repository-wide XACML policy.  This means you cannot use a repository-wide policy to forbid users to see any objects, and then use XACML to grant viewing rights on particular objects.   However, object-specific XACML can deny rights that are allowed at the Fedora-wide level. You can author object-level XACML policies (to the DSID and role level) by using the XACML Editor - ready for review (KB)

...