Use case 1 - Fedora managing access conditions

Title (goal)
Fedora managing access conditions
Primary ActorLibrarian/archivist/curator
Scope 
LevelUser goal
Story

The producer of Fedora content wants to be able to set access conditions that would allow for the following scenarios:

  1. Content can only be accessed by a specific IP address or list of addresses
  2. Data streams in the object can have different access conditions. i.e. TIF restricted to a single user, JPG open to the campus, PDF open to the world.
  3. Curator can set authorization in an external system which Fedora can access.
    1. EZProxy
    2. homegrown authorization systems
  4. Curator can adjust access conditions per object or for thousands/millions of objects at a time
  5. Curator can set restrictions on the application permitted to open an object. (focus on born digital for this)
    1. example: Disk image created for a Mac SE, the curator indicates in the access condition the emulation environment required to open the file.
    2. note 1: I'm not expecting Fedora to enforce the restriction, only to store it.
    3. note 2: I know emulation information can be stored in PREMIS, but information about the required emulation settings is different from requiring a specific software title.
  6. Curators can set multiple access schemas to an object or data stream in an object. This means a curator could say that a set of IP addresses, an active directory group and a special group in our identity management software may access the materials.
  7. Curators can set an access restriction flag for an external patron registration system or other complex authorization system such as Aeon (Atlas Systems). In this case, we only need Fedora to know that the restriction exists. We would apply the code that reacts to this requirement in Hydra or some other system which would cause the patron to go off and register/login to some patron tracking system and when they meet the requirements, Hydra/Blacklight would release the objects that meet the requirement.

As for implementation, I can offer some examples of what we use now. We specify the file type/size, the authorization type and then any values associated. Some examples:

TIF - Active Directory Group - ManuscriptCurators

TIF - Aeon

JPG 600px - IP - list of IP values or ranges

PDF - external authentication

JPG 1200px - Yale only

JPG 150px - open access

TIF - NetID - yale\mf438 (or a list of NetIDs)

DSK - Active Directory Group - ManuscriptDirectors

DSK - Emulation - AppleWin v1.1.8

Basically our need is for very granular levels of permission to be stored with the object in Fedora. Right now it is stored as XML as a data stream, it would be beneficial to have it stored differently so that we could make mass changes to materials for entire collections.

Another note, we would only be storing a single JPG or possibly no JPG and only a JP2 and will derive the JPG on the fly. So the access condition setup may include conditions for resolutions of digital formats not contained in the data streams. The JPG examples above would indicate that a single JPG exists as a data stream and from that stream we will derive smaller images. But the access conditions are different for ranges of sizes. For Yale, we stick to these sizes, 150px or less (thumb), 151-600px (medium), 600+ (full resolution). For TIF images we use Full, Half page and Quarter page. Right now, all other sizes/resolutions are tied directly to the file type stored as a data stream. But being able to reference access for something that is dynamically generated would make this scale to future needs.

4 Comments

  1. David Wilcox

    1. This could be satisfied by creating a new Principle Provider to collect the IP address, and that information could be used in the existing authorization framework.
    2. Andrew Woods will test to see if this functionality currently exists.
    3. Custom authentication provider plugins can be written for each external system.
    4. See this use case.
    5. Need some additional information on desired behaviour. Does Fedora actually need to provide any functionality as per requirement 5b?
    6. This may be a good candidate for a XACML implementation.
    7. Does Fedora need to provide any particular functionality to address this requirement?

    For the final paragraph, on the fly derivatives will not be supported in Fedora 4.0.

     

    1. Andrew Woods

      Regarding item #2, yes, access controls can currently be assigned down to the datastream level.

      It would be instructive to see if Michael Friscia could verify this is also true from Yale's perspective.

  2. Michael Friscia

    IP addresses have recently come into some scrutiny here at Yale as we move to private IP addresses. While I am confident that we will retain static IP addresses specifically for very secure content where we need to have a trusted connection between a computer and Fedora, I'm wondering if there are any thoughts to come up with some form of token/response method of providing content to a target computer without a static IP and to also securely encrypt the content during transfer. I'm kind of thinking out loud but thought it would be worth adding that as we start to move into storing data sets and other types of content that require significant layers of security on them into our repositories, it would be worth talking more about potential security layers to adopt.

     

    I'll get the programmers to test the data stream level access controls to confirm this possibility.

    1. Andrew Woods

      some form of token/response method of providing content to a target computer without a static IP and to also securely encrypt the content during transfer

      Without getting into potential implementations (token/response), it may be worth describing what you would like to achieve (such as, authorize access to unauthenticated users from within the institutional network, etc).

      For transfer encryption, is SSL not sufficient?

      Honestly, there is a lot going on in this use case. If we want to be able to address Yale's needs, we will need to break these into smaller pieces and prioritize. Any help you can offer regarding prioritization of your individual pieces would be helpful.

All content on the LYRASIS Wiki is licensed under the CC BY (Attribution) license, unless otherwise noted.