Authorization and Authentication With RBAC (Part 2)

authorization and authentication are important to couchbase. in march, i blogged about some of the new role-based access control (rbac) that we are showing in the couchbase server 5.0 developer builds. this month, i’d like to go into a little more detail now that the april couchbase server 5.0 developer build is available (make sure to click the developer tab).

authentication and authorization

in past version of couchbase, buckets were secured by a password. in 5.0, bucket passwords for authorization are gone. you can no longer create a “bucket password” for authorization. instead, you must create one (or more) users that have varying levels of authorization for that bucket. notice that there is no “password” field anymore (not even in the advanced bucket settings ):

so now, you no longer have to hand out a password that gives complete access to a bucket. you can fine-tune bucket authorization and give out multiple sets of credentials with varying levels of access. this will help you tighten up security and reduce your exposure.

note: the administrator user still exists, and has permission to do everything. so i can still run n1ql queries (for instance) on that bucket while logged in as an administrator account. however, this is not the account you should be using from your clients.

creating an authorized user

to create a new user, you must be logged in as an administrator (or as a user that has an admin role). go to the security tab, and you’ll be able to see a list of users, nd be able to add new ones.

create a new user by clicking add user . enter the information for the user. you may want to create a user for a person (i.e. “matt”), or you may want to create a user for a service (i.e. “myaspnetapplication”). make sure to enter a strong password, and then select the appropriate roles for the user you want to create.

for example, let’s create a user “matt” that only has access to run select queries on the bucket i just created. in roles , i expand query roles , then query select , and check the box for mynewbucket , and then save to finalize the user.

authorization in action

when i log out of the administrator account, and log back in as “matt” i can see that the authorization level i have is severely restricted. only dashboard , servers , settings , and query are visible. if i go to query , i can execute select 1 :

if i try something more complex, like select count(1) from mynewbucket , i’ll get an error message like:

[
  {
    "code": 13014,
    "msg": "user does not have credentials to access privilege cluster.bucket[mynewbucket].data.docs!read. add role data reader[mynewbucket] to allow the query to run."
  }
]

so it looks like i have the correct authentication to log in and i have the correct authorization to execute a select , but i don’t have the correct authorization to actually read the data. i’ll go back in as admin, and add data reader authorization.

at this point, when i login with “matt” select count(1) from mynewbucket; will work. if you are following along, try select * from mynewbucket; . you’ll get an error message that no index is available. but if you try to create index you’ll need another permission to do that. you get the idea.

new n1ql functionality

there’s some new n1ql functionality to go along with the new authentication and authorization features.

grant and revoke role

you can grant and revoke roles with n1ql commands. you need admin access to do this.

here’s a quick example of granting select query authorization to a user named “matt” on a bucket “mynewbucket”:

grant role query_select( mynewbucket ) to matt;

and likewise, you can revoke a role doing something similar:

revoke role query_select( mynewbucket ) from matt;

creating users with rest

there is no way (currently) to create users with n1ql, but you can use the rest api to do this. full documentation is coming later, but here’s how you can create a user with the rest api:

• put to the /settings/rbac/users/builtin/<username> endpoint.
• use admin credentials for this endpoint (i.e. administrator:password with basic auth).
• the body should contain:
  • roles=<role1,role2,…,role> .
    
  • password=<password> .
    

below is an example. you can use curl, postman , fiddler , or whatever your favorite tool is to make the request.

url: put http://localhost:8091/settings/rbac/users/builtin/restman

headers: content-type: application/x-www-form-urlencoded
authorization: basic qwrtaw5pc3ryyxrvcjpwyxnzd29yza==

body: roles=query_select[mynewbucket],query_update[mynewbucket]&password=password

the above assumes that you have an admin user/password of administrator/password (hence the basic auth token of qwrtaw5pc3ryyxrvcjpwyxnzd29yza==).

after executing that, you’ll see a new user named “restman” with the two specified permissions.

but wait, there’s more!

the rbac system is far too rich to cover in a single blog post, and full documentation is on its way. in the meantime, here are some details that might help you get started with the preview:

• you may have noticed the all option in the screenshots above. you can give a user roles on a bucket-by-bucket basis, or you can give permission to all buckets (even buckets that haven’t been created yet).
• i covered fts permissions in the previous blog post, but there are permissions that cover just about everything : views, bucket administration, backup, monitoring, dcp, indexes, etc.
• you can’t create buckets with a password anymore . the equivalent is to instead create a user with the name as the bucket, and give it authorization to a role called “bucket full access.” this will be useful for upgrading and transitioning purposes.