Harry, how many users have you tried with this scheme ?
I am myself considering something for a demo app but not sure if it scales to 
thousands or hundreds of thousands or millions of users.

There is also the issue that if you want to share a large set of documents to a 
new user (say 10,000 docs) then those 10,000 docs need to be "touched' (e.g. 
read and written),
this could be a heavy operation.

The alternative, which is not as elegant but might perform better is to keep 
access lists as data (say in an XML file or files) and handle the access 
control at the user level.
You are right this is not as clean nor proven as using the system level access 
control but it might be
* faster
* easier

By Faster, if you decide to share 10,000 with a new user then you need only 
update 1 file (but then if this gets to be a big file you might end up having 
problems.
By *easier* there are less operations required to add a new user.

Another option might be to store the access list of a document in document 
properties.   You still have to touch the same number of files but potentially 
smaller changes
(assuming the access list is smaller then the document) and you can do property 
based searches combined with document searches so no "joining" required.

I think this would make a great paper or blog

"How to handle access control of large numbers of users and documents"


-David


-----------------------------------------------------------------------------
David Lee
Lead Engineer
MarkLogic Corporation
[email protected]
Phone: +1 812-482-5224
Cell:  +1 812-630-7622
www.marklogic.com<http://www.marklogic.com/>


From: [email protected] 
[mailto:[email protected]] On Behalf Of Harry B.
Sent: Wednesday, December 11, 2013 8:29 AM
To: General MarkLogic Developer Discussion
Subject: Re: [MarkLogic Dev General] Document Level Authorization (Roles and 
Users)


You haven't missed anything. The approach I have used many times is to maintain 
roles for each user and have also modeled user "groups" the same way. I 
recommend following a naming convention because at some point you'll want to be 
able to build UI tools and will want to only show roles for the app or have 
predictive names.

What I mean is if my application is called "ABC", all my role names would have 
a prefix like "abc-john-brown"

One other consideration would be a role for each user to indicate the owner, so 
for John Brown, I would have abc-john-brown role that is added to documents 
John Brown shares from others and abc-john-brown-owner for all documents that 
belong to John Brown.

I know it seems like a lot of roles and duplicated effort, but what is nice is 
that you can leverage solid, proven security on the documents without and 
performance hit you'd take with controlling access using application logic.

Let me know if I can help. I've done this a few times and managed it with SSO 
solutions as well.

Harry
On Dec 11, 2013 6:13 AM, "Timothy W. Cook" 
<[email protected]<mailto:[email protected]>> wrote:
I am planning an application and working on the security plan.

Users will each have a collection to store their documents.  At various times 
they will want to share some of these documents with other users. Typically 
read only.  Having read through the vast amount of information, I still do not 
see where a document creator would be able to add read capability for a single 
user of a single document. The only approach I can see would be to create A LOT 
of different Roles.

What have I missed?

Thanks,
Tim


--
MLHIM VIP Signup: http://goo.gl/22B0U
============================================
Timothy Cook, MSc           +55 21 94711995<tel:%2B55%2021%2094711995>
MLHIM http://www.mlhim.org
Like Us on FB: https://www.facebook.com/mlhim2
Circle us on G+: http://goo.gl/44EV5
Google Scholar: http://goo.gl/MMZ1o
LinkedIn Profile:http://www.linkedin.com/in/timothywaynecook

_______________________________________________
General mailing list
[email protected]<mailto:[email protected]>
http://developer.marklogic.com/mailman/listinfo/general
_______________________________________________
General mailing list
[email protected]
http://developer.marklogic.com/mailman/listinfo/general

Reply via email to