Thanks for these tips about collections. I have been thinking about a slightly different approach that may work with protected collections, document properties and one or more amped function(s).
Each user has a unique 'home' directory. In that directory is a subdirectory called 'shared'. This shared directory is where Sue puts all of her documents that she wants to share with anyone. The sharing process is via a function that gives the other user (Tom) Read permissions on all existing documents in Sue's shared directory. Tom then, via a function activated by Sue, gets a new collection added to his directory that contains (but they are really references, not copies, correct?) all of those documents. Because of the association established between Sue and Tom, there will be occasions that Tom will create documents that are about Sue. These documents should go into Sue's shared directory. So Tom has to have Create and Update permissions in this directory as well. I am not sure that I completely understand the scope of inherited permissions though. I want to Tom to be able to Update documents that he created but only Read the other documents created by Sue or another user. I think this fits the standard security model? I believe that a Role/user that grants the Read/Create permissions to the shared directory would accomplish this. I haven't yet worked out all of the required document properties needed because some of this will not fit in the standard security model. But I certainly want to fit everything possible within that model. Users will only have access to the DB via REST API apps and a dashboard (unless there is a breach of course). :-( So I am fairly confident in using amped functions to handle the Role and Permission assignments. Again, thanks for your comments. --Tim On Mon, Jul 28, 2014 at 8:08 PM, Danny Sokolsky < [email protected]> wrote: > For your question about collections, there are 2 types of collections, > “collections” and “protected collections”. Collections have no security > associated with them, and a document can have many (or no) collections, but > access to the document is simply by permissions. > > > > Protected collections are a bit different, and in general, I would not > recommend using them. They create a document in the security database, and > they only affect access to the documents when asking for them **by > collection** (ie, using fn:collection). When accessing a document by a > protected collection, you need to have permissions on both the collection > and the document. > > > > -Danny > > > > *From:* [email protected] [mailto: > [email protected]] *On Behalf Of *Timothy W. Cook > *Sent:* Monday, July 28, 2014 3:52 PM > *To:* MarkLogic Developer Discussion > *Subject:* Re: [MarkLogic Dev General] Security Design > > > > Thanks Danny. I was hoping to get a discussion around this because I am > not sure it is as simple as I first thought. > > I had not considered using amped functions to do it. > > > > Of course this was just a three person example. The real use case > involves Sue needing to have the ability to share read access to several > other users on documents where she only has read access. > > > > At this point I have minimal exposure to the way MarkLogic handles > document level security and trying to relate this to the documentation in > the Search Guide on Collections security. So, I think this needs good > planning before jumping into implementation. > > > > A specific question is; do I understand correctly that a document can be > in many collections and that collection access must be granted before > document access is checked? > > > > --Tim > > > > On Mon, Jul 28, 2014 at 7:31 PM, Danny Sokolsky < > [email protected]> wrote: > > Hi Tim, > > > > I am not sure I have thought this through completely, nor can I think of > the exact steps to do this, but here is my instinct on how I would attempt > to solve this: > > > > I would try to create amped functions that allow Sue to share (read only) > Tom’s document (that Sue has read permission for). I think the function > could amp to a role paired with a read permission on the document, thus > allowing Tom to read the document. > > > > Like I said, I am not totally sure how I would write such a function, but > it seems possible (though tricky). See if that scratches an itch. > > > > Maybe someone else has a better idea. > > > > -Danny > > > > *From:* [email protected] [mailto: > [email protected]] *On Behalf Of *Timothy W. Cook > *Sent:* Monday, July 28, 2014 7:19 AM > *To:* MarkLogic Developer Discussion > *Subject:* [MarkLogic Dev General] Security Design > > > > I am in the early design stages of a (hopefully) large application and > would like to see if I understand the operations of collections correctly. > > > > You can think of this in a similar context to a social media app. > > I have attached a simple diagram to aid the text. > > > > Imagine that Joe, Sue and Tom are users and each have a collection (marked > 'P' )where only they have read/write access to documents they load. > > Joe and Tom have collections that they would like to use to share (read > only) with various other users, one being Sue. This seems rather straight > forward. > > However, the use case also calls for Sue being able to share (read only) > Tom's documents with Joe and Joe's documents with Tom; as she sees fit > without the intervention of Tom or Joe. > > > > Could someone expand on this to describe how this might be setup? Do I > need separate roles that are tied to each collection, for each of these > exchanges? > > > > Thanks, > > Tim > > > > > -- > > > ============================================ > Timothy Cook > LinkedIn Profile:http://www.linkedin.com/in/timothywaynecook > > MLHIM http://www.mlhim.org > > > > > _______________________________________________ > General mailing list > [email protected] > http://developer.marklogic.com/mailman/listinfo/general > > > > > > -- > > > ============================================ > Timothy Cook > LinkedIn Profile:http://www.linkedin.com/in/timothywaynecook > > MLHIM http://www.mlhim.org > > > > _______________________________________________ > General mailing list > [email protected] > http://developer.marklogic.com/mailman/listinfo/general > > -- ============================================ Timothy Cook LinkedIn Profile:http://www.linkedin.com/in/timothywaynecook MLHIM http://www.mlhim.org
_______________________________________________ General mailing list [email protected] http://developer.marklogic.com/mailman/listinfo/general
