Scenario 6: Access to “non-published” material

By “non-published” material in the repository, we mean material that is only accessible to an individual or to an identified group of people. Examples are: (i) “work in progress”, where the author may only wish a small group of users to have access; (ii) research data that is stored in a repository while it is still being worked with, and where access is restricted to the members of the research group; (iii) research funding bodies that want access to project outputs for management and reporting purposes; (iv) external examiners requiring access to material in a local repository; (v) e-portfolio use cases, where an external assessor needs to access repository material (e.g. for a job application). In all these examples the access may cross institutional boundaries.

In examples (iii)-(v), a number of external individuals are granted access to certain resources held in the repository. These individuals are in general all independent of one another. Assuming that their home institutions belong to the federation, and that they are employed by the hosting institution on a relatively regular basis, the simplest solution appears to be an eduPersonEntitlement provided by their home IdPs.

The situation in examples (i) and (ii) is more complex; here, a repository forms (part of) a working environment, or “virtual research environment”. Some people may deny repositories that such a role is appropriate; however, such systems are being developed and are likely to become more common in the future. A more specific example is collaborative word processing, such as Scribd and GoogleDocs; although the outputs are not at present stored in repositories, this may change – indeed, a JISC-funded project is already doing this for GoogleDocs . The research data scenario is common in grid environments, which are frequently used to manage data from large scientific projects. In some cases different data environments are used in parallel for different roles (raw data, derived data, associated material, backup, etc.), for example in the LHC model.

Role-based access management, and delegation rights for access management, are of relevance here. Much technical work in this area has been done – for example, the PERMIS and DyVOSE (Dynamic Virtual Organisations for e-Science Education) projects. This approach requires some actor in the scenario to look after the policies –

in the “research group” scenarios (examples (i)-(ii) above) this might be the PI, in the “assessment” scenarios (examples (iii)-(v)) this might be the head of assessment.

A closely related issue is group management, and “virtual organisations”, in which access rights are given to groups of individuals (e.g. in VREs). In principle, groups could be defined by using eduPersonEntitlement to encode this information, but this would require the IdPs to be involved in group management, by setting up bilateral agreements between the SP and each of the IdPs. This is undesirable for a number of reasons: it would require coordination of the IdPs, which are external to the group, and whose managers may not appreciate the additional work; it would require the group to place significant trust in the IdPs, who would have full power to add the entitlement to individuals in their organisation. Another approach is to

An alternative is a system like VOMS (Virtual Organisation Management System), which is being used in the SARoNGS (Shibboleth Access to Resources on the NGS) project for grid access management . However, this is a heavyweight mechanism that may not be flexible enough to support all these use cases. It takes a significant amount of work to set up groups in this way (perhaps a week to set up a new VO). Although this is not too onerous for long-term research projects, in many cases it is necessary to set up ad hoc groups quickly from the bottom up. The VPMAN project has made some progress here, by bridging role-based privileges and VOMS, and this may be integrated into SARoNGS. The GFIV0 project is addressing these issues using Grouper. Note: this also relevant to Scenario 10.

Proposed actions:

Commision some early adopter projects piloting approaches to collaborative work in IRs. These projects should involve real users (teachers, learners and researchers) and should use existing collaborative tools. The projects could look either at collaborative authoring (e.g. of documents) or at collaborative work on research data.

In the case of research data, important issues to address are: (i) the granularity of the access decisions that need to be made; (ii) the need for lightweight group/VO management. These projects should build on previous work such as Grouper and GFIV0.

It would also be useful to produce a summary of relevant use cases and technologies, and to produce a synthesis.


Submitted by

Stage: Active

Feedback Score

2 votes

Idea Details

Vote Activity

  1. Upvoted
  2. Upvoted

Similar Ideas [ 4 ]


  1. Comment
    Unsubscribed User

    Role based access for repositories offers a good place to start examining in more detail the need for universal taxonomies around access roles as there is a well understood workflow around the publication process.

  2. Comment

    Again this emerged as potentially important last time; the idea of moving repositories "upstream" in the researcher's work flow, so that it becomes a help to the researcher rather than an added burden.

  3. Comment

    The work of the FLAME project is definitely of relevance here, using a combination of a group management system (home-grown, after problems with Signet) and a mechanism for adding individual external users to those which can be managed within the group. This is designed particularly to meet the requirement above in examples (iii)-(v) in a more general context. Both these tools are intended to be as lightweight as possible.

    Similarly, the Flamespace application developed to test these tools is another example of the type of VRE tool mentioned, being a collaborative WIKI, where individuals can share their own areas.

  4. Comment

    This is a general comment on the use of eduPersonEntitlement values.

    In order for such a value to be of use, it needs to be defined by the SP and IdP involved (or a federation containing both) and then assigned to appropriate individuals by the IdP owner. This can only be done by one of:

    a) updating information in the directory (or, potentially, one of several directories) used by the IdP to obtain attribute values

    b) configuring the IdP to add this value to a specified list of users (which may be a "list" in the sense of "all those who have a group membership in an appropriate group"

    In both cases, a fair amount of administrative work is needed by the IdP-owner, particularly if, as is true in many HEIs, the directory is maintained by a different division from the IdP (e.g. by IT Services and the Library respectively). Whether or not proper processes for updates have been put in place, changes are likely to be slow and this means that inaccuracies are likely.

    This is not of course inevitable, but is a reflection of the way things are at the moment.

    In most of the use cases described here, it would make more sense for the SP-owner to compile an access control list as part of their SP configuration or as part of the resource/repository being accessed, and use some other attribute such as eduPersonTargetedId to determine whether or not the user is in the ACL.

    The easiest way to manipulate ePE values in close to real time is to use a group management tool such as Grouper, and until such tools become commonplace, use of ePE will remain difficult.

  5. Comment
    Unsubscribed User

    Re Nicole's comment on universal taxonomies for access roles, the Terena REFEDS group could have some input here. Following up on Simon McLeish's comment on Grouper, usage is getting wider, it seems, so maybe a solution worth looking at further?

Add your comment