On Wednesday, June 6, 2012, Mark Diggory wrote:
>
>
> On Wednesday, June 6, 2012, helix84 wrote:
>
>
>> On Wed, Jun 6, 2012 at 5:31 PM, Mark Diggory <mdigg...@atmire.com> wrote:
>> > Now, the only important thing is that we want to be careful about
>> exposing
>> > policies that probably should not be known to the world in
>> > OAI, Public Exports and DRI for unauthenticated users. Here we go, now
>> we
>> > have a good example of the need for Expressing "Access Controls" on
>> > "Metadata Sections" in the metadata for all dialog.
>
>
>
>> Hmm, so there would be effectively "permission on access to list of
>> permissions"? What would be the use case for hiding access to access
>> policies?
>
>
> Personally, I never thought it good to expose the DRI or METS used in
> rendering the ui publically outside the ui. It...
>
> A) forces us to worry about questions like securing access to the content
> used in rendering decisions that should not be shared with the world.
>
> B) conflates the content generation phase of the UI as a Public API...
> Which it really shouldn't be. We do not guarantee any of these exposed
> renderings as an API.
>
> Generally, it's rather insecure to expose the write permissions on
> resources, your going to be telling any attackers the names of accounts or
> groups of accounts to try to hack depending on those policies. Since they
> have access to the code, they can work to find a vulnerability. There's
> being open, then there's being foolhardy.
>
If we do not put resource policies on resource policies, then the
permissions need to be hardcoded into the app ( like we have for admin and
collection managers ) access administrative options and interfaces. The
later is probibly easier than the former.
Also... We might consider that with METS, theres the possibility that the
rights description can reside external of the METS document itself in a
separate request, it's this request that can be access controlled and/or
filtered based on user rights at the XMLUI generation phase, the relative
path to this generator can be traversed in the same manner that the METS
representation is gotten out of the DRI "Resource" URI using a document()
call in xslt.Meaning we don't shoehorn all this into ItemAdapter, but
instead create separate pipelines for rendering different parts of the METS
object model to XML for use in transformations.
Mark
--
[image: @mire Inc.]
*Mark Diggory *(Schedule a Meeting <https://tungle.me/markdiggory>)
*2888 Loker Avenue East, Suite 305, Carlsbad, CA. 92010*
*Esperantolaan 4, Heverlee 3001, Belgium*
http://www.atmire.com
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
DSpace-tech mailing list
DSpace-tech@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dspace-tech
