[
https://jira.duraspace.org/browse/DS-908?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=20391#action_20391
]
Mark H. Wood commented on DS-908:
---------------------------------
Such a scheme can give code enough information to explain in detail why access
was denied. Good.
DSpace has for some time needed centralization of access control. There should
be one place you go to ask, "may I access object X on behalf of user Y for
purpose Z?" If yes: return void. If no: throw an Exception containing a
reference to the denying policy and a message text with as much specific detail
as it is reasonable for a central authority to derive from the failure. The
catching code may of course add any of its own knowledge relevant to the
problem, and should.
Any request for a reference to an unauthorized object should receive one of
these Exceptions. UIs (including PMH, SWORD, etc.) should not be making access
decisions.
I'm a bit concerned about terminology. What we have now could be called
"static inheritance" of policies, and what is suggested could be called
"dynamic inheritance". Also, resource policies *are* metadata, so we need to
be careful to qualify that word.
I agree that the warning related to DS-525 really indicates that in this area
DSpace is tricky to use. The warning is a good work-around, but we should
relieve the administrator of this complication if we can.
> Embargo Overhaul: Utilize ResourcePolicy Start and Stop datestamps for
> enforcing embargo in DSpace
> --------------------------------------------------------------------------------------------------
>
> Key: DS-908
> URL: https://jira.duraspace.org/browse/DS-908
> Project: DSpace
> Issue Type: Improvement
> Components: Discovery, Documentation, DSpace API, JSPUI, LNI,
> OAI-PMH, REST API (experimental), Service Manager, Solr, SWORD, Unit Testing
> Framework, XMLUI
> Affects Versions: 1.6.2, 1.7.0, 1.7.1
> Reporter: Mark Diggory
> Priority: Major
> Fix For: 1.8.0
>
>
> I would like to readdress how the current embargo is implemented in DSpace,
> this Issue comes up because we have started working on an Embargo solution
> that actually uses the start/end dates of resource policies to enforce the
> embargo rather than a cron tab script. This approach is currently under
> deployment/test in IDEALS and based on existing embargo work that was
> completed there by
> The new proposed approach would allow for Embargo to be applied at either the
> Item level or individual Bitstream levels as a series of ResourcePolicies
> that use start/stop datestamps currently on the ResourcePolicy object and
> does not require executing a cronjob to adjust the state of the Item Thus the
> record and enforcement of embargo is stateless. Being stateless means that
> the policies do not change over time, just the resulting decision of the
> evaluation that enforces of those policies changes.
> The AuthorizationManager already supports the enforcement of timeframes in
> ResourcePolicies. I would like to propose that we expand ResourcePolicy in
> the following manner:
> 1.) To be a better DSpace Domain Model citizen and that would include having
> name and description fields available to define the reason for a resource
> policy being set.
> 2.) Establishment of a RESTRICT Action that would be enforced by the
> AuthorizationManager to allow for "Explicit Definition" of the Embargo Policy
> on Annonymous Users.
> For example:
> Bitstream A --> ResurcePolicy( Action=RESTRICT, Group=Annonymous,
> start=20110101, end=20120101, name="Embargo", description="Embargoed as
> required by publisher.")
> Bitstream A --> ResurcePolicy( Action=READ, Group=UniversityAffiliates,
> start=null, end=null, name="Local University Affiliates", description="Local
> University Affiliates are Exempt from Embargo Restriction.")
> The previous example would enforce Embargo and Access rights "Explicitly" and
> "Clearly" in the Policies attached to the Bitstream and/or Item. The
> AuthorizationManager may need minor enhancement to address "inheritance" of
> ResourcePolicies assigned on parent Items. It may be advisable to use such
> inheritance to enforce "DEFAULT_XXX" policies rather than copying them into
> place on each and every Bitstream/Bundle and Item created, this will reduce
> the "bloat" of ResourcePolicies currently in effect in the existing system.
> And important benefit of these changes to ResourcePolicies and the underlying
> AuthorizationManager framework are that they can then be used to encode the
> explicit technical or administrative metadata sections into the AIP or METS
> manifests concerning the Policies that are in effect on the Item and its
> contents. Adjustments to the DSpace SIP Profile to capture enforcement of
> embargo details by consumers of those tools would be more clearly expressed
> and machine automatable than dumping it intot he metadata. Achieving Machine
> actionability means that Ingest Packagers and services that rely on them can
> define a more concrete business logic to be maintained.
> As we evolve the Metadata capabilities to support
> system/tech/admin/descriptive metadata sections for all parts of the item, we
> can consider that the ResourcePolices will inform the production of metadata
> about the embargo state of the Item being exposed in OAI / SWORD /METS
> packagers and so-on. But for now, we really need to set a standard that
> actual Resource Policies be the mechanism that enforces the access
> rules/policies within the system and not some metadata field set in the item
> metadata description.
> Somewhat a concern is how other areas of DSpace treat ResourcePolicies rather
> bluntly. Recommend that ResourcePolicies should be managed in central manner
> (such as ResourcePolicyService: or "ResorcePolicyManager") such that the
> manner in which policies are enforced or allowed to be edited does NOT cause
> emergent conflicting behavior across different parts of the system such as
> those described within DS-906 and DS-525.
> According the DS-525, the issue of embargoed items is documented as a warning
> in our Documentation:
> https://wiki.duraspace.org/display/DSDOC/System+Administration#SystemAdministration-Movingitems
>
> I consider this documentation insufficient as a solution to the problem of
> embargo permissions getting overridden in the mapping. A more appropriate
> solution would show to the user the exact changes that would happen to the
> item and allow them to decide which policies should be enforce/changed on the
> item.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://jira.duraspace.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
------------------------------------------------------------------------------
What Every C/C++ and Fortran developer Should Know!
Read this article and learn how Intel has extended the reach of its
next-generation tools to help Windows* and Linux* C/C++ and Fortran
developers boost performance applications - including clusters.
http://p.sf.net/sfu/intel-dev2devmay
_______________________________________________
Dspace-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/dspace-devel
