Authorizations / Permitted Data

[Peter Dietz]

Hi All,

I'm at the 80/20 point in the Jersey implementation. (i.e. 80% of the features, for 20% effort). It has endpoints for (communities, collections, items, bitstreams), you can follow the relationship to get to the child/parent objects, and you can retrieve bitstreams. 

I'm trying to bake in some controls that limit the exposure of sensitive information, i.e. authorization.

if(AuthorizeManager.authorizeActionBoolean(context, community, org.dspace.core.Constants.READ)) {
  //Code to respond with Community
} else{
  //You are not authorized to view this Community
}

So, this is tricky, because the community-list, gives you all communities, even possibly "Dark" communities, that are not anonymous readable. We have 99 public communities, but 1 dark community. 

Should the community-list for the public user give you all 100 communities, or just give you 99. Of course when you try to go to the suppressed community you get a proper not-authorized message. I'm just wondering what one would expect. 

The approach that I'm going to follow is to evict not-authorized-for-this-user objects from the response. My thinking, is don't give someone a big red button that says danger, unless their name is Max.

for(org.dspace.content.Community community : topCommunities) {

  if(AuthorizeManager.authorizeActionBoolean(context, community, org.dspace.core.Constants.READ)) {

    //Only list communities that this user has access to.

    org.dspace.rest.common.Community restCommunity = new org.dspace.rest.common.Community(community, expand, context);

    communityArrayList.add(restCommunity);

  }

}

While typing all of this, I've gone through and slapped an initial if(Auth...) check on each of these endpoints. The code feels a bit too verbose, and I'm not yet outputting error messages in a friendly manner. (i.e. you get an HTTP response of 401(NotAuth) or 500(Server Error) ), but its not xml or json, but more of a tomcat stack-trace.

Jersey atleast gives me an easy way to throw errors. throw new WebApplicationException(Response.Status.UNAUTHORIZED);

My next clean-up is going to be on provenance metadata.

[helix84]

Hi Peter,

my thinking here is that REST API is not for direct human use, but for
machines. Therefore you shouldn't withhold information from the
client, but provide all needed information and let it make an informed
decision. Depending on what exactly you mean by dark community (AFAIK
resource policies affect read access to items, not containers; but
maybe you mean the non-discoverable flag), it would be wiser to add an
attribute/element that denotes it as such. Such list would be much
easier to process (I'm thinking XSLT here, but also relevant to any
other machine processing), e.g. //community[@discoverable!="false"],
rather than having no way that there are such dark objects or having
to explicitly ask for them.


Regards,
~~helix84

[Tim Donohue]

+1 to what helix84 says.

Essentially, it'd be nice if the client (which is using the REST API)
could decide whether to display all 100 communities, just 99 of them, or
perhaps put a lock icon next to the one community which has
@discoverable=false.

[Peter Dietz]

All DSpace Objects have direct permission policies. You can have (READ, WRITE, ADD, REMOVE, ADMIN), and it can be applied to an eperson or epersongroup. This lives in Edit Community -> Assign Roles -> Edit Authorization Policies.

My vote is to use DSpace's AuthorizeManager as our gate-keeper. Thus, once I figure out AuthN, and can get other users to log-in to the API, i.e. AdminUser or ArchivesManager, then their use of API gives them access to archives-secret-lair community. And not worry about accidental resource exposure. 

For Items, I'm thinking it might make sense to bring along additional information about the status of the Item, (withdrawn, inArchive, embargo, private, ...).

P.S. I have just solved the issue of limiting exposure of sensitive metadata.

By using: if (!MetadataExposure.isHidden(context, dcv.schema, dcv.element, dcv.qualifier)) {

Peter Dietz