Access Controls

Access Controls in Hydra

This document is incomplete; please contribute if you can.

Developer questions can also be directed to the hydra-tech list or the freenode #projecthydra IRC channel.

See also hydra-access-controls README.

Some old page content (from Duraspace wiki)

(this section needs to be vetted / revised / expanded! (2012-04-13) )

Custom Models & RightsMetadata

If you are using your own custom models, you need to make sure to use the hydra rightsMetadata datastream (see xxx models for examples). The information you put into the rightsMetadata datastream will be indexed and used to enforce access permissions.

class MyModel < ActiveFedora::Base
  has_metadata :name => "rightsMetadata", :type => Hydra::Datastream::RightsMetadata
  # to use Hydra methods to manage rightsMetadata:
  include Hydra::ModelMixins::RightsMetadata
end

Using Admin Policy Objects (APOs)

See the Hydra project wiki for more information. You can create APOs with the Hydra::AdminPolicy class or your own subclass. To allow your custom model to be governed by an APO, add this to your class:

class MyModel < ActiveFedora::Base
  # ...
  belongs_to :admin_policy, :property=>:is_governed_by
end

Modifying solr field names for enforcement

Hydra uses its own set of default solr field names to track rights-related metadata in solr. If you want to use your own field names, you can change them in your Hydra config. You will also have to modify the permissions response handler in your solrconfig.xml to return those fields.

1. config/initializers/hydra_config.rb
   

   Hydra.configure(:shared) do |config|
     # ... other stuff ...
     config[:permissions] = {
       :catchall => "access_t",
       :discover => {:group =>"discover_access_group_t", :individual=>"discover_access_person_t"},
       :read => {:group =>"read_access_group_t", :individual=>"read_access_person_t"},
       :edit => {:group =>"edit_access_group_t", :individual=>"edit_access_person_t"},
       :owner => "depositor_t",
       :embargo_release_date => "embargo_release_date_dt"
     }
     config[:permissions][:inheritable] = {
       :catchall => "inheritable_access_t",
       :discover => {:group =>"inheritable_discover_access_group_t", :individual=>"inheritable_discover_access_person_t"},
       :read => {:group =>"inheritable_read_access_group_t", :individual=>"inheritable_read_access_person_t"},
       :edit => {:group =>"inheritable_edit_access_group_t", :individual=>"inheritable_edit_access_person_t"},
       :owner => "inheritable_depositor_t",
       :embargo_release_date => "inheritable_embargo_release_date_dt"
     }
   end

Solr Index Sanity Check

This check ensures that the rightsMetadata from your objects is being indexed correctly.

Refresh the Fixture objects

rake hydra:default_fixtures:load

… or load them if you haven’t loaded them yet

rake hydra:default_fixtures:refresh

Now examine the xml returned from this url:

http://localhost:8983/solr/development/select/?q=id:hydrangea\:fixture_mods_article1%0D%0A&start=0indent=on

(Note: if you’re not using the bundled jetty, or if you’re testing your production Solr instance, you have to replace [http://localhost:8983/solr/development] with the URL for your copy of Solr.

Among many other things, it should include this:

<arr name="read_access_group_t"><str>public</str></arr>

Likewise, the xml returned from this url:

http://localhost:8983/solr/development/select/?q=id:hydrangea\:fixture_archivist_only_mods_article%0D%0A&start=0&indent=on

should include:

<arr name="edit_access_group_t"><str>archivist</str></arr>

If this is not the case, then your objects are not being indexed correctly. This will cause your objects to be “hidden” because Hydra’s access controls default to denying access to objects when the rightsMetadata info is not available in Solr.

How Permissions are Expressed in Hydra rightsMetadata

How Permissions are Indexed into Solr Documents

How you can use Alternative Field Names in Solr to Enforce Permissions

The Access Controls Evaluation helpers

In your controllers and views you can test whether the current user has read or edit permissions on the current document by calling {reader?} or {editor?}

To test another type of permission, you can use {test_permission?}

Assigning “Public” permissions

In order to give permissions to the public (including users who are not logged in), simply grant group permissions for the “public” group. For example, to give the public “read” permissions, add this to the rightsMetadata

  <access type="read">
    <machine>
      <group>public</group>
    </machine>
  </access>

This will add “public” to read_access_t in solr.