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]> 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
> 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]
> http://developer.marklogic.com/mailman/listinfo/general
>
>
_______________________________________________
General mailing list
[email protected]
http://developer.marklogic.com/mailman/listinfo/general

Reply via email to