{
"type": "fulltext-index",
"name": "hotels",
"sourceType": "couchbase",
"sourceName": "travel-sample",
// ... snip ...
}Authentication and Authorization with RBAC
This is a repost that originally appeared on the Couchbase Blog: Authentication and Authorization with RBAC.
In March’s developer build, you can start to see some major changes to authentication and authorization within Role Based Access Control (RBAC) coming to Couchbase Server. These changes are a work in progress: the developer build is essentially a nightly build that gets released to the public. But there’s some good stuff in RBAC that’s worth getting excited about!
Go download the March 5.0.0 developer release of Couchbase Server today. Make sure to click the "Developer" tab to get the developer build (DB), and check it out. You still have time to give us some feedback before the official release.
Keep in mind that I’m writing this blog post on early builds, and some things may change in minor ways by the time you get the release, and some things may still be buggy.
Authentication and Authorization
Just a quick reminder of the difference between authentication and authorization:
-
Authentication is the process of identifying that a user is who they say they are.
-
Authorization is the process of making sure the user has permission to do what they are trying to do.
If you’ve used Couchbase before, you’re familiar with the login to what we sometimes call the "Admin Web Console".
However, the Web Console is really not just for admins, it’s for developers too. But until now, you didn’t really have a lot of control built-in to Couchbase about who can log in and (more importantly) what they’re allowed to do.
So, I’d like to introduce you to Couchbase’s new first-class user feature.
Users
There’s still a full administrator user. This is the login that you create when you first install Couchbase. This is the user who is unrestricted, and can do anything, including creating new users. So, for instance, a full administrator can see the "Security" link in the navigation, while other users can’t.
Now, once on this security page, you can add, edit, and delete users.
A user can identify a person, but it can also identify some service or process. For instance, if you’re writing an ASP.NET application, you may want to create a user with a limited set of permissions called "web-service". Therefore, the credentials for that "user" would not be for a person, but for an ASP.NET application.
Next, try adding a new Couchbase user by clicking "+ Add User". I’m going to create a user called "fts_admin", with a name of "Full Text Search Admin", a password, and a single role: FTS Admin of the travel-sample bucket (FTS = Full Text Search).
Adding a new User
Here’s an animation of adding that user:
Some notes about the above animation:
-
I selected "Couchbase" instead of "External". External is meant for LDAP integration. Note that "Couchbase" (internal authentication) will likely become the default in future releases.
-
FTS Admin gives the user permission to do everything with Full Text Searches: create, modify, delete, and execute them.
-
I granted FTS Admin only for the travel-sample bucket. If I selected "all", that would grant permission to all buckets, even ones created in the future.
-
Users with the FTS Searcher role only have access to execute searches, not modify or create them.
More on the difference between FTS Admin and FTS Searcher later.
Logging in as a new user
Now that this user is created, I can login as fts_admin. This user’s authentication is handled within Couchbase.
First, in the above animation, note that the fts_admin user has a much more limited set of options compared to the full admin user.
Next, it’s worth pointing out that users can reset their password:
Creating an FTS index
Since I’ve already created an fts_admin user with the FTS Admin role, I’ll create another user called fts_searcher that only has the FTS Searcher role for the travel-sample bucket.
Using the REST API for FTS
I’m going to use the REST API to demonstrate that these users are limited by the roles I’ve given them. If you need a refresher on the REST API, you can refer to the documentation of the Full Text Search API. Also note that I’m using the REST API because there are some bugs in the UI as I’m writing this.
Create an FTS index
To create an index with the REST API, I need to make a PUT request to the /api/index/<indexname> endpoint.
-
First, I’ll create an index for the 'hotel' type in the travel-sample bucket, so I’ll PUT to
/api/index/hotels -
Also, credentials can be put in the URL to use basic authentication
-
Furthermore, the REST endpoints are available on port 8094
Finally, the URL for the PUT request should look something like this:
The body of the PUT is a big JSON object. Below is part of it. You can find the full version on GitHub to try for yourself.
Normally, you can create this via the UI instead of having to create JSON by hand. I’m not going to go into FTS in much detail in this post, because my goal is to demonstrate the new authentication and authorization features, not FTS itself.
Trying to create an index without authorization
Notice that I’m using fts_searcher as the user. I know that fts_searcher shouldn’t have permission to create indexes, so I would expect a 403. And that’s just what I get.
{
"message": "Forbidden. User needs one of the following permissions",
"permissions": [
"cluster.bucket[travel-sample].fts!write"
]
}So, while the authentication worked, that user doesn’t have the necessary authorization.
Creating an index with authorization
I’ll try again with fts_admin:
And assuming an index named 'hotels' doesn’t already exist, you’ll get a 200, and this in the body of response:
{
"status": "ok"
}Using the FTS index
Next, let’s use the REST API to search the index for the word 'breakfast'.
First, make a POST to the /api/index/hotels/query endpoint, again with the proper credentials and port number.
or
Both users should be able to execute a search using that index.
Next, in the body of the POST should be a simple JSON object. Again, you don’t normally have to create this by hand — your SDK of choice or the Web Console UI can do this for you.
{
"explain": true,
"fields": [
"*"
],
"highlight": {},
"query": {
"query": "breakfast"
}
}Finally, the result of this search request will be a large JSON response. Look within the "hits" sub-document for "fragments" to verify that the search worked. Here’s a snippet of my search for "breakfast". Again, the full result is on Github.
// ... snip ...
"reviews.content": [
"… to watch TV. <mark>Breakfast</mark> was served every morning along with a copy of the Times-Picayune. I took my <mark>breakfast</mark> downstairs in the patio, the coffee was very good. The continental <mark>breakfast</mark> is nothing to…"
]
},
// ... snip ...This is a preview, expect some bugs!
There are some bugs and some incomplete features.
-
I’ve shown FTS roles here on purpose. This is because the other roles are not yet fully formed. Please try them out, let us know what you think, but remember they are not in their final form. FTS is closest to ready.
-
I’ve seen some issues when logging in as a non-admin user causes the web console to behave badly. Because of this, I showed the REST example above instead of relying on the UI.
-
Finally, there might be other bugs that we don’t know about yet. Please let us know! You can file an issue in our JIRA system at issues.couchbase.com or submit a question on the Couchbase Forums. Or, contact me with a description of the issue. I would be happy to help you or submit the bug for you (my Couchbase handlers send me a cake pop when I submit a good bug).
If you have questions, the best way to contact me is either Twitter @mgroves or email me matthew.groves@couchbase.com.
