javascript - How can I structure a MongoDB query to evaluate a permission chain with allow and deny with my ACL? -
i designing per-document acl app using mongodb. trying accomplish next characteristics:
anyfind or update's query can optionally extended specially-constructed acl query determine whether find or update permitted. hence permission check doesn't increment number of database queries, , particular app, not cut down performance because of index intersection. documents back upwards permissions users have no log in (unauthorized), users logged in (authorized), , specific users. permissions can specified allow or deny. i having problem implementing deny permissions in performant way.
how can construction mongodb query evaluate permission chain allow , deny specs?
an illustration document:
var permission = 1; { somedata: "test", // acl info construction security: { unauthorized: { allow: [permission] }, authorized: { allow: [permission] }, users: [ {_id: "userid", allow:[], deny:[permission]} ] } } the intent here users unauthorized (have no logins) , users authorized (have logins), can permission document. particular user id "userid" cannot permission.
what mongodb query correctly evaluate permission chain?
here's current query have:
{"$or": [ // top of permission chain { "security.unauthorized.allow": permission, "security.unauthorized.deny": {"$ne": permission} }, // middle of permission chain { "security.authorized.allow": permission, "security.authorized.deny": {"$ne": permission} }, // bottom of permission chain { "security.users._id": "userid", "security.users.allow": permission, "security.users.deny": {"$ne": permission} } ]} when evaluating chain broadest-to-finest control, allow evaluations work. there deny permission deeper in chain, query doesn't work, illustration above.
the thoughts acl design here pretty interesting: database schema acl. discusses mapping conceptual, role, concretely architectural, permission. problem me solved. i'm having problem solving deny permission problem without introducing query chain inverted.
in particular, if there way combine array element match, "security.users._id": "userid" deny check "security.users.deny": {$ne: permission}, solve deny problem—i check finest-grain deny @ top of chain , finest-grain allow @ bottom.
if had $xor operator (http://en.wikipedia.org/wiki/xor), this:
{"$or": [ { "security.unauthorized.allow": permission, "security.unauthorized.deny": {"$ne": permission}, "security.authorized.deny": {"$ne": permission}, "$xor": [ {"security.users._id": "userid"}, {"security.users.deny": permission} ] }, { "security.authorized.allow": permission, "security.authorized.deny": {"$ne": permission} }, { "security.users._id": "userid", "security.users.allow": permission, "security.users.deny": {"$ne": permission} } ]} i can build $xor, suspicion performance characteristics poor.
i'd take totally different schema , construction too.
here basic solution, though has bad performance characteristics.
var generateaclquery = function (userid, permission) { // if userid specified, check whole permissions chain homecoming userid ? { $or: [ // in permission chain, evaluate broadest permission downwards finest. { "security.unauthorized.allow": permission, "security.unauthorized.deny": {$ne: permission}, // have check if @ finer level, no deny occurs "security.authorized.deny": {$ne: permission}, $or: [ {"security.users._id": {$ne: userid}}, {"security.users._id": userid, "security.users.deny": {$ne: permission}} ] }, { "security.authorized.allow": permission, "security.authorized.deny": {$ne: permission}, // again, check if @ finer level, no deny occurs $or: [ {"security.users._id": {$ne: userid}}, {"security.users._id": userid, "security.users.deny": {$ne: permission}} ] }, { "security.users._id": userid, "security.users.allow": permission, "security.users.deny": {$ne: permission} } ] } : { // otherwise, if userid null or undefined, check unauthorized permission "security.unauthorized.allow": permission, "security.unauthorized.deny": {$ne: permission} } }; javascript mongodb security data-structures acl
No comments:
Post a Comment