Add rest-reader to the app-specific role

[dmcassel]

The app role needs to have rest-reader to use any REST API endpoints, and rest-writer to call any that make changes. I propose adding rest-reader and a commented-out rest-writer:

<role>
  <role-name>@ml.app-role</role-name>
  <description>A role for users of the @ml.app-name application</description>
  <role-names>
    <role-name>rest-reader</role-name>
    <!-- <role-name>rest-writer</role-name> -->
  </role-names>

These should be added at least for all --app-type=rest apps, and since that's our focus, we might as well just make it the default. Comments?

[grtjn]

How about rest-extension-user?

[paxtonhare]

It's better to add privileges than roles. Dave, I still owe you that blog
post on app level security and REST api, but it's how you have to do it.
Using roles will let users see data they shouldn't see.

[dmcassel]

Geert, the rest-reader role inherits rest-extension-user.

[dmcassel]

Paxton, the rest-reader role provides the rest-reader execute privilege and inherits rest-extension-user. We already give the app-role read and update permissions on content loaded via "deploy content". I don't follow how adding privileges would be better than adding the rest-reader role here.

[grtjn]

Roles might be necessary to have access to modules.. :-(

[grtjn]

Revisiting this issue. I agree with Paxton that you are better off with rest-reader/rest-writer privilege (instead of role). Content/module/trigger/schema access should be arranged with read/exec/update/.. permissions through app-role..

But it does make a lot of sense to at least add those two privs to the sample ml-config user. That will also help the slush template..

[grtjn]

Needs some rethinking before moving forward. Postponing this for now..

[grtjn]

Adding it back to 1.7.3, have some thoughts on this, and it would definitely help the slush generator..

[grtjn]

I'd still recommend using rest privs instead of roles. However, next to rest-reader/-writer priv, you'd need rest extensions (that get installed via official way) to get at least read/exec permission assigned to rest options, transforms, extension modules, and such. Next to this, if you really intent to write, you need either any-collection/any-uri, or specific protected collections, and uri privs as well..

[grtjn]

(e.g. lets push this away till next release..)

[patrickmcelwee]

+1. I run into this with every demo I build.

Reading through this, I still don't understand why privileges are better than roles. Is that written up anywhere? In particular, in what way is what @paxtonhare wrote true for the rest roles: "Using roles will let users see data they shouldn't see."?

[dmcassel]

@patrickmcelwee All documents inserted through the REST API ends up with rest-reader having read privileges; thus, all those documents are visible to users who have the rest-reader role. If you don't want that, then you give your user a role that has the rest-reader role (so that access will work), but not the rest-reader role. Samplestack does this so that guest users can only see certain contact.

[grtjn]

:), I think @dmcassel meant to say: "give your user a role that has the rest-reader privilege (so that access will work), but not the rest-reader role. Samplestack does this so that guest users can only see certain content."

[grtjn]

It is slightly more complicated. You need rest privs to be allowed to use the REST api itself. It does some has-priv checks. Then to be allowed to execute modules, rest extensions, and read content, they all need doc-permissions for a role that the user has. I tend to apply read,update,exec to all modules/extensions, and read/update to all content, but only for the ml.app-role. That way I am sure only users belonging to the app I am working on are allowed to access content, and run extensions/code belonging to it..

[grtjn]

In short, privs give you more control over access..

[patrickmcelwee]

Thanks for the explanations @dmcassel and @grtjn !

[popzip]

I wrote a blog post in an effort to spread the explanation above more widely and to walk through Samplestack's implementation. Hope that helps illustrate.

[grtjn]

Yes, thanks. Looks in line with my own thoughts, which I converted into this PR against slush-marklogic-node: marklogic-community/slush-marklogic-node#298

[grtjn]

That PR is a bit hard to read, but ml-config.xml is being patched in slushfile.js (for the time being, until we agree on this, and are ready to apply a fix in Roxy itself)..