access control options?

[mwaschkowski]

I have a client that has groups of users, each group of which
shouldn't see the data from the others (typical access control issue).
What options do I have with Mongo to best handle this requirement?

Thank you,

Mark

[Kyle Banker]

Have you looked at our docs on authentication?

http://www.mongodb.org/display/DOCS/Security+and+Authentication

One options would be to create a separate database per user.  Hard to help out without knowing more about your use case.

--
You received this message because you are subscribed to the Google Groups "mongodb-user" group.
To post to this group, send email to mongod...@googlegroups.com.
To unsubscribe from this group, send email to mongodb-user...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/mongodb-user?hl=en.

[mwaschkowski]

OK, I saw from an old version of the docs:

http://www.mongodb.org/pages/viewpage.action?pageId=132926

that there is no access control in the database itself. I'm assuming
this is still true? Any plans for addition in the future? If not, any
suggestions/links on how to implement this at the application level?

Thank you,

Mark

[Kyle Banker]

There currently exists per-database access control. You can add users and authenticate with them.

http://www.mongodb.org/display/DOCS/Security+and+Authentication

[mwaschkowski]

Hi,

Yes, saw that, but I'm referring to access control on the data in the
system, not authentication into the system.

http://en.wikipedia.org/wiki/Access_control#Authorization
(Mandatory access control) section

So, our system currently only allows users to see the documents they
are authorized to see via an AccessManager. The AccessManager in our
system is a java interface that we implemented some business rules in,
and all queries are (eventually) fed through this to see if a
particular user is allowed to retrieve a particular document, based on
some attributes assigned to the document itself. The business rules
that define the permission granting aren't important, just that there
was a hook (in this case an java interface that we implemented) in the
backend system to allow us to write the rules to restrict access to
documents.

I appreciate your help, is that clear enough or should I provide more
detail?

Thank you,

Mark

On Feb 18, 5:43 pm, Kyle Banker <k...@10gen.com> wrote:
> Have you looked at our docs on authentication?
>
> http://www.mongodb.org/display/DOCS/Security+and+Authentication
>
> One options would be to create a separate database per user.  Hard to help
> out without knowing more about your use case.
>

> On Thu, Feb 18, 2010 at 5:23 PM, mwaschkowski <mwaschkow...@gmail.com>wrote:
>
>
>
> > I have a client that has groups of users, each group of which
> > shouldn't see the data from the others (typical access control issue).
> > What options do I have with Mongo to best handle this requirement?
>
> > Thank you,
>
> > Mark
>
> > --
> > You received this message because you are subscribed to the Google Groups
> > "mongodb-user" group.
> > To post to this group, send email to mongod...@googlegroups.com.
> > To unsubscribe from this group, send email to

> > mongodb-user...@googlegroups.com<mongodb-user%2Bunsubscribe@google groups.com>

[Kyle Banker]

Right. There's no fine-grained access control built into the database itself. Nothing to stop you from building an application layer that works similarly to your AccessManager, though.

To unsubscribe from this group, send email to mongodb-user...@googlegroups.com.

[Eliot Horowitz]

We added read-only users in 1.3.2 but that's it.

On Feb 18, 2010, at 5:57 PM, mwaschkowski <mwasch...@gmail.com>
wrote:

> Hi,

[Vitaliy V. Shopov]

Do you planning per collection access control?

2010/2/19 Eliot Horowitz <elioth...@gmail.com>

mongodb-user...@googlegroups.com<mongodb-user%2Bunsubscribe@google groups.com>

.
For more options, visit this group at
http://groups.google.com/group/mongodb-user?hl=en.

--
You received this message because you are subscribed to the Google Groups "mongodb-user" group.
To post to this group, send email to mongod...@googlegroups.com.
To unsubscribe from this group, send email to mongodb-user...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/mongodb-user?hl=en.

[Eliot Horowitz]

We have no current plans yet.
If you think its important, can add a jira case to track interest (votes).
We're not opposed to it, just very low on the priority list.

[Vitaliy V. Shopov]

Np, think so that feature will be in application's layer)

[mwaschkowski]

OK, I've created the following issue:

http://jira.mongodb.org/browse/SERVER-648

I could be wrong, but I don't think this is as well suited to doing in
the application layer. Whats needed is an interface or hook of some
kind that indicates a document should be included in a result set
returned from the db.

For max speed, I can see doing it from the app layer. If you were to
implement AC there, you would have to create one query that defines
your criteria on the documents to retrieve, and then funnel that
criteria to a single class that would make the db call which would
then add on addition criteria as a sub select to say something like:

original criteria + 'where user.level in doc.acl'

Because of limiting the result set size via the where clause, the
query would (I'm guessing) be faster, but with indexes probably not
much. As well, if the user belonged to multiple groups, that where
clause would get bigger/more complicated, which just has a bad smell
to it.

In summary, AC is a global type restriction, and should be treated as
such at the database level, which is the gatekeeper of the data.

On Feb 18, 9:06 pm, Eliot Horowitz <eliothorow...@gmail.com> wrote:
> We have no current plans yet.
> If you think its important, can add a jira case to track interest (votes).
> We're not opposed to it, just very low on the priority list.
>
> On Thu, Feb 18, 2010 at 9:04 PM, Vitaliy V. Shopov
>
>
>
> <shopov.vita...@gmail.com> wrote:
> > Do you planning per collection access control?
>

> > 2010/2/19 Eliot Horowitz <eliothorow...@gmail.com>

>
> >> We added read-only users in 1.3.2 but that's it.
>