The software used will most likely be Islandora or something we will develop ourselves. But having all the security policies once place would from my point of view be the most optimal solution for us. But as you mention yourself, it is not possible to base policies on XML datastreams yet.
On Thu, Jul 28, 2011 at 12:32 PM, Stephen Bayliss <stephen.bayl...@acuityunlimited.net> wrote: > Are there perhaps a couple of concerns here - what the software should do in > terms of creating and populating a request, plus an enforcement layer to > disallow illegal requests? Of course if the software behaves perfectly then > the enforcement layer isn't needed, but it could be useful to have the > enforcement layer to ensure compliance. > > It does seem reasonable to me to base XACML policies on resource content (an > attribute finder based on XML datastreams has already been suggested) - and > it would also seem reasonable that the resource content could include the > content-to-be-added. > > Though it may be possible to do what you want bypassing the enforcement > layer and do it all by intercepting the request as Asger suggests. > > Steve > >> -----Original Message----- >> From: Asger Askov Blekinge [mailto:a...@statsbiblioteket.dk] >> Sent: 27 July 2011 12:24 >> To: fedora-commons-users@lists.sourceforge.net >> Subject: Re: [fcrepo-user] Controlling values in objects on creation >> >> >> Hi >> >> There are a few ways of doing what you want. Basically, what >> you want is >> NOT a policy. The example you gave was that new objects should get to >> include specific content, based on the user roles. Changing the >> behaviour of a method is not the domain of policies. >> >> You want to do >> 1. Ensure that all objects belong to an org >> 2. Automatically setting the objects org to the users org >> 3. Disallow the explicit creation of objects with a different >> org than >> the users org. >> >> 1. Can be done with enhanced content models. Make a >> requirement that all >> objects must have the <k2rdf:orgid/> relation. >> >> 2. Can be done with a fedora decorator (search for this in >> fedora.fcfg, >> is it one of the hidden features). Basically write a >> decorator that does >> something like this >> if method is ingest >> do ingest >> orgIDvalue = getOrgIDfromUserObject >> removeAllRelations(orgidRelation) >> addRelation(orgidRelation, orgIDvalue) >> >> Based on your example, I take it you also want to disallow >> the moving of >> a document from one organisation to another. As otherwise, I >> would just >> be able to create the document, and then change it's orgid to >> something bad. >> >> As such, the easiest thing would probably be to write yet another >> decorator, that intercepts the method addDatastream, >> modifyDatastream*, >> addRelation, purgeRelation, and checks if you attempt to change the >> RELS-EXT datastream and the orgid relation. >> >> >> Regards >> Asger >> >> On 27/07/11 12:57, Tomasz Cielecki wrote: >> > Hello Stephen, >> > >> > To elaborate a bit more. We have some organisations each with some >> > users a part of these organisations. A user can only be in one >> > organisation. A user can have a role, the bigger the role the more >> > access the user gets. The most basic role is where the user gets to >> > access all public data, and make local objects within the >> > organisation. >> > >> > So lets say one of these basic users want to make a document. As >> > described this document will only be available in the >> organisation as >> > the user is only allowed to create it here. And then to be >> extra sure >> > we want to create a policy that disallows users to create >> them outside >> > of the organisation. >> > >> > On each object we have some RELS-EXT describing that the object >> > belongs to an organisation: >> > <k2rdf:orgid>xxx</k2rdf:orgid> >> > >> > So if the user belongs to orgid 42 then the newly created object is >> > has to have the line: >> > <k2rdf:orgid>42</k2rdf:orgid> >> > in the RELS-EXT. >> > >> > >> > Now another use case. >> > A user with an admin role inside this organisation is allowed to >> > create new users with roles that have less permissions than >> his own. >> > These users are created as objects in Fedora where their >> data is in a >> > Datastream consisting of XML. >> > >> > On Tue, Jul 26, 2011 at 7:46 PM, Stephen Bayliss >> > <stephen.bayl...@acuityunlimited.net> wrote: >> >> Hi Tomasz >> >> >> >> At a high level I think what you are saying fits within XACML - >> >> though I'm not sure how much will be present within the >> current FeSL >> >> implementation. >> >> >> >> It is possible to base policies on the content that is >> being added - >> >> for instance in the modifyDatastream method it is possible to >> >> restrict access based on the new value of MIMEType (instead of the >> >> existing value). >> >> >> >> One thing we have not implemented yet is resource >> attributes based on >> >> datastream XML content - so the ability to restrict access >> based on >> >> node values in an XML datastream. I see no reason in >> principle why >> >> this couldn't be extended to cover also the XML content >> being added >> >> as well as the existing content (though I'm not sure of the >> >> implications on implementing this - especially how a Resource >> >> AttributeFinderModule would be set up to operate on the >> to-be-added >> >> content rather than the existing content). >> >> >> >> And it is possible to construct policies comparing subject and >> >> resource attributes, so in theory it should be possible to compare >> >> your (subject) role with a role specified in the content >> to be added. >> >> >> >> Would it be possible for you to describe in a little more >> detail your >> >> use case? >> >> >> >> Regards >> >> Steve >> >> >> >>> -----Original Message----- >> >>> From: Tomasz Cielecki [mailto:tom...@ostebaronen.dk] >> >>> Sent: 25 July 2011 15:02 >> >>> To: Support and info exchange list for Fedora users. >> >>> Subject: [fcrepo-user] Controlling values in objects on creation >> >>> >> >>> >> >>> Hey fedora users, >> >>> >> >>> I think I got the hang of writing policies now but I want >> to know if >> >>> it is possible to somehow control the values when, say, >> creating a >> >>> new object called user in the database? For instance if I the >> >>> subject that wants to create a new object only have the >> permission >> >>> of creating a user with the same role as I have and roles >> that have >> >>> less permissions than my role. >> >>> >> >>> Or another example. If a subject belonging to a specific >> >>> organization is only allowed to create objects of the type note >> >>> within his own organization? >> >>> >> >>> Is that even possible with an XACML policy? >> >>> >> >>> -- >> >>> With Best Regards >> >>> Tomasz Cielecki >> >>> >> >>> -------------------------------------------------------------- >> >>> ---------------- >> >>> Storage Efficiency Calculator >> >>> This modeling tool is based on patent-pending >> intellectual property >> >>> that has been used successfully in hundreds of IBM storage >> >>> optimization engage- ments, worldwide. Store less, Store >> more with >> >>> what you own, Move data to the right place. Try It Now! >> >>> http://www.accelacomm.com/jaw/sfnl/114/51427378/ >> >>> _______________________________________________ >> >>> Fedora-commons-users mailing list >> >>> Fedora-commons-users@lists.sourceforge.net >> >>> https://lists.sourceforge.net/lists/listinfo/fedora-commons-users >> >>> >> >> >> >> >> >> >> --------------------------------------------------------------------- >> >> --------- >> >> Magic Quadrant for Content-Aware Data Loss Prevention >> >> Research study explores the data loss prevention market. >> Includes in-depth >> >> analysis on the changes within the DLP market, and the >> criteria used to >> >> evaluate the strengths and weaknesses of these DLP solutions. >> >> http://www.accelacomm.com/jaw/sfnl/114/51385063/ >> >> _______________________________________________ >> >> Fedora-commons-users mailing list >> >> Fedora-commons-users@lists.sourceforge.net >> >> https://lists.sourceforge.net/lists/listinfo/fedora-commons-users >> >> >> > >> > >> > >> >> >> -------------------------------------------------------------- >> ---------------- >> Got Input? Slashdot Needs You. >> Take our quick survey online. Come on, we don't ask for help >> often. Plus, you'll get a chance to win $100 to spend on >> ThinkGeek. http://p.sf.net/sfu/slashdot-survey >> _______________________________________________ >> Fedora-commons-users mailing list >> Fedora-commons-users@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/fedora-commons-users >> > > > ------------------------------------------------------------------------------ > Got Input? Slashdot Needs You. > Take our quick survey online. Come on, we don't ask for help often. > Plus, you'll get a chance to win $100 to spend on ThinkGeek. > http://p.sf.net/sfu/slashdot-survey > _______________________________________________ > Fedora-commons-users mailing list > Fedora-commons-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/fedora-commons-users > -- Med Venlig Hilsen / With Best Regards Tomasz Cielecki http://ostebaronen.dk ------------------------------------------------------------------------------ Got Input? Slashdot Needs You. Take our quick survey online. Come on, we don't ask for help often. Plus, you'll get a chance to win $100 to spend on ThinkGeek. http://p.sf.net/sfu/slashdot-survey _______________________________________________ Fedora-commons-users mailing list Fedora-commons-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/fedora-commons-users
