You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@usergrid.apache.org by sn...@apache.org on 2015/08/03 23:28:28 UTC
incubator-usergrid git commit: Replacing Apigee,
App Services and API BaaS references.
Repository: incubator-usergrid
Updated Branches:
refs/heads/ug2-doc-update e17b48889 -> acae95913
Replacing Apigee, App Services and API BaaS references.
Project: http://git-wip-us.apache.org/repos/asf/incubator-usergrid/repo
Commit: http://git-wip-us.apache.org/repos/asf/incubator-usergrid/commit/acae9591
Tree: http://git-wip-us.apache.org/repos/asf/incubator-usergrid/tree/acae9591
Diff: http://git-wip-us.apache.org/repos/asf/incubator-usergrid/diff/acae9591
Branch: refs/heads/ug2-doc-update
Commit: acae95913e6cefc15f3343f03418229bcde5da0d
Parents: e17b488
Author: Dave Johnson <sn...@apache.org>
Authored: Mon Aug 3 17:27:53 2015 -0400
Committer: Dave Johnson <sn...@apache.org>
Committed: Mon Aug 3 17:27:53 2015 -0400
----------------------------------------------------------------------
.../authenticating-api-requests.md | 6 +++---
...henticating-users-and-application-clients.md | 14 ++++++-------
docs/security-and-auth/facebook-sign.md | 22 ++++++++++----------
.../security-and-auth/revoking-tokens-logout.md | 2 +-
docs/security-and-auth/securing-your-app.md | 6 +++---
.../user-authentication-types.md | 16 +++++++-------
docs/security-and-auth/using-permissions.md | 4 ++--
7 files changed, 35 insertions(+), 35 deletions(-)
----------------------------------------------------------------------
http://git-wip-us.apache.org/repos/asf/incubator-usergrid/blob/acae9591/docs/security-and-auth/authenticating-api-requests.md
----------------------------------------------------------------------
diff --git a/docs/security-and-auth/authenticating-api-requests.md b/docs/security-and-auth/authenticating-api-requests.md
index c48bebd..af52bf6 100644
--- a/docs/security-and-auth/authenticating-api-requests.md
+++ b/docs/security-and-auth/authenticating-api-requests.md
@@ -1,8 +1,8 @@
# Authenticating API requests
-With the exception of the 'sandbox' application that is created with every API BaaS organization, all applications are secured by default. This means that to access your data store, a valid access token must be sent with all API requests to authenticate that the requester is authorized to make API calls to the resources they are attempting the access.
+With the exception of the 'sandbox' application that is created with every Usergrid organization, all applications are secured by default. This means that to access your data store, a valid access token must be sent with all API requests to authenticate that the requester is authorized to make API calls to the resources they are attempting the access.
-This article describes how to use access tokens to access the API BaaS API, and how to manage access tokens, including revoking and changing token time to live.
+This article describes how to use access tokens to access the Usergrid API, and how to manage access tokens, including revoking and changing token time to live.
For information on generating access tokens/authenticating users and clients, see Authenticating users and application clients.
@@ -18,7 +18,7 @@ You can include the token in an HTTP authorization header:
Authorization: Bearer {access_token}
<div class="admonition note"> <p class="first admonition-title">Note</p> <p class="last">
-Note: The API BaaS documentation assumes you are providing a valid access token with every API call whether or not it is shown explicitly in the examples. Unless the documentation specifically says that you can access an API endpoint without an access token, you should assume that you must provide it. One application that does not require an access token is the sandbox application. The Guest role has been given full permissions (/** for GET, POST, PUT, and DELETE) for this application. This eliminates the need for a token when making application level calls to the sandbox app. For further information on specifying permissions, see Managing access by defining permission rules.
+Note: The Usergrid documentation assumes you are providing a valid access token with every API call whether or not it is shown explicitly in the examples. Unless the documentation specifically says that you can access an API endpoint without an access token, you should assume that you must provide it. One application that does not require an access token is the sandbox application. The Guest role has been given full permissions (/** for GET, POST, PUT, and DELETE) for this application. This eliminates the need for a token when making application level calls to the sandbox app. For further information on specifying permissions, see Managing access by defining permission rules.
</p></div>
## Authenticating with client ID and client secret
http://git-wip-us.apache.org/repos/asf/incubator-usergrid/blob/acae9591/docs/security-and-auth/authenticating-users-and-application-clients.md
----------------------------------------------------------------------
diff --git a/docs/security-and-auth/authenticating-users-and-application-clients.md b/docs/security-and-auth/authenticating-users-and-application-clients.md
index 54dded0..eaa52f4 100644
--- a/docs/security-and-auth/authenticating-users-and-application-clients.md
+++ b/docs/security-and-auth/authenticating-users-and-application-clients.md
@@ -1,6 +1,6 @@
# Authenticating users & app clients
-To protect your App Services application data, one of the steps you'll take is to authenticate your app's users. By ensuring that they are who they say they are, you can help ensure that your application's data is available in secure ways. After you've created permission rules that define access to your application and have associated these rules with users, you'll want to add code that authenticates your user, as described in this topic.
+To protect your Usergrid application data, one of the steps you'll take is to authenticate your app's users. By ensuring that they are who they say they are, you can help ensure that your application's data is available in secure ways. After you've created permission rules that define access to your application and have associated these rules with users, you'll want to add code that authenticates your user, as described in this topic.
<div class="admonition note"> <p class="first admonition-title">Note</p> <p class="last">
You manage access to your application's data by creating permission rules that govern which users can do what. Users authenticated as Application User have access according to these rules. For more about managing permissions, see [Using Permissions](using-permissions.html).
@@ -8,7 +8,7 @@ You manage access to your application's data by creating permission rules that g
## Authentication levels
-App Services supports four levels of authentication:
+Usergrid supports four levels of authentication:
* __Application user__: Grant's user access to an API Services application, based on the roles and permissions assigned to the user.
* __Application client__: Grants full access to perform API requests against an API Services application.
@@ -20,10 +20,10 @@ Because the scope of access provided by the application client, organization cli
For a more detailed description of available authentication levels, see [Authentication levels](user-authentication-types.html).
## Application user authentication (user login)
-Using the username and password values specified when the user entity was created, your app can connect to the App Services application endpoint to request an access token. It's also acceptable to use the user's email address in place of the username.
+Using the username and password values specified when the user entity was created, your app can connect to the Usergrid application endpoint to request an access token. It's also acceptable to use the user's email address in place of the username.
### Using the SDKs
-When a user is logged in using the Apigee iOS, JavaScript, node.JS and Android SDKs, the returned token is automatically stored in the ApigeeDataClient (iOS), DataClient (Android), or Apigee.Client (JavaScript/node.JS) class instance, and will be sent to the API with all subsequent method calls.
+When a user is logged in using the Usergrid iOS, JavaScript, node.JS and Android SDKs, the returned token is automatically stored in the UsergridDataClient (iOS), DataClient (Android), or Usergrid.Client (JavaScript/node.JS) class instance, and will be sent to the API with all subsequent method calls.
#### Request syntax
@@ -46,7 +46,7 @@ The results include the access token needed to make subsequent API requests on b
}
## Application client authentication
-Using your app’s client id and client secret values, your app can connect to the App Services application endpoint to request an access token. The client ID and secret for your app can be found in 'Getting Started' section of the API Services admin portal, under 'Server App Credentials'.
+Using your app’s client id and client secret values, your app can connect to the Usergrid application endpoint to request an access token. The client ID and secret for your app can be found in 'Getting Started' section of the API Services admin portal, under 'Server App Credentials'.
<div class="admonition warning"> <p class="first admonition-title">WARNING</p> <p class="last">
Warning: You should never authenticate this way from a client-side app such as a mobile app. A hacker could analyze your app and extract the credentials for malicious use even if those credentials are compiled and in binary format. See "safe mobile access" in [Authenticating API requests](authenticating-api-requests.html) for additional considerations in keeping access to your app and its data secure.
@@ -73,7 +73,7 @@ The results include the access token needed to make subsequent API requests on b
}
## Admin user authentication
-If you do require admin user access, your app can connect to the App Services management endpoint to request an access token. Your app supplies the username and password of an admin user in the request.
+If you do require admin user access, your app can connect to the Usergrid management endpoint to request an access token. Your app supplies the username and password of an admin user in the request.
<div class="admonition warning"> <p class="first admonition-title">WARNING</p> <p class="last">
Warning: Authenticating as an admin user grants full access to one or more organizations and all of the applications contained in those organizations. Due to this, be cautious when implementing this type of authentication in client-side code. Instead, consider implementing admin user access in server-side code only. See "safe mobile access" in [Authenticating API requests](authenticating-api-requests.html) for additional considerations in keeping access to your app and its data secure.
@@ -100,7 +100,7 @@ The results include the access token needed to make subsequent API requests on b
}
## Organization client authentication
-If you do require organization level access, your app can connect to the App Services management endpoint to request an access token. Access to an organization requires the client id and client secret credentials. The client ID and secret for your organization can be found on the 'Org Administration' page of the API Services admin console under 'Organization API Credentials'.
+If you do require organization level access, your app can connect to the Usergrid management endpoint to request an access token. Access to an organization requires the client id and client secret credentials. The client ID and secret for your organization can be found on the 'Org Administration' page of the API Services admin console under 'Organization API Credentials'.
<div class="admonition warning"> <p class="first admonition-title">WARNING</p> <p class="last">
Warning: You should never authenticate this way from a client-side app such as a mobile app. A hacker could analyze your app and extract the credentials for malicious use even if those credentials are compiled and in binary format. See "safe mobile access" in [Authenticating API requests](authenticating-api-requests.html for additional considerations in keeping access to your app and its data secure.
http://git-wip-us.apache.org/repos/asf/incubator-usergrid/blob/acae9591/docs/security-and-auth/facebook-sign.md
----------------------------------------------------------------------
diff --git a/docs/security-and-auth/facebook-sign.md b/docs/security-and-auth/facebook-sign.md
index 55be0de..e2c7411 100644
--- a/docs/security-and-auth/facebook-sign.md
+++ b/docs/security-and-auth/facebook-sign.md
@@ -1,14 +1,14 @@
# Facebook sign in
-You can authenticate your App Services requests by logging into Facebook. To access App Services resources, you need to provide an access token with each request (unless you use the sandbox app). You can get an access token by connecting to an appropriate web service endpoint and providing the correct client credentials — this is further described in Authenticating users and application clients. However, you can also obtain an access token by logging into Facebook.
+You can authenticate your Usergrid requests by logging into Facebook. To access Usergrid resources, you need to provide an access token with each request (unless you use the sandbox app). You can get an access token by connecting to an appropriate web service endpoint and providing the correct client credentials — this is further described in Authenticating users and application clients. However, you can also obtain an access token by logging into Facebook.
-To enable authentication to App Services through Facebook, do the following in your app:
+To enable authentication to Usergrid through Facebook, do the following in your app:
1. Make a login call to the Facebook API (do this using the Facebook SDK or API). If the login succeeds, a Facebook access token is returned.
-2. Send the Facebook access token to App Services. If the Facebook access token is valid and the user does not already exist in App Services, App Services provisions a new App Services user. It also returns an App Services access token, which you can use for subsequent App Services API calls. Behind the scenes, App Services uses the Facebook access token to retrieve the user's profile information from Facebook.
+2. Send the Facebook access token to Usergrid. If the Facebook access token is valid and the user does not already exist in Usergrid, Usergrid provisions a new Usergrid user. It also returns an Usergrid access token, which you can use for subsequent Usergrid API calls. Behind the scenes, Usergrid uses the Facebook access token to retrieve the user's profile information from Facebook.
3. If the Facebook access token is invalid, Facebook returns an OAuth authentication error, and the login does not succeed.
-The request to authenticate to App Services using a Facebook access token is:
+The request to authenticate to Usergrid using a Facebook access token is:
GET https://api.usergrid.com/{my_org}/{my_app}/auth/facebook?fb_access_token={fb_access_token}
@@ -21,7 +21,7 @@ where:
## Facebook login example
The Facebook technical guides for login present detailed information on how to add Facebook login to your app. Instructions are provided for JavaScript, iOS, and Android.
-In brief, here are the steps for JavaScript. You can see these steps implemented in the Facebook login example packaged with the JavaScript SDK for App Services (which you can download in ZIP format or tar.gz format). The Facebook login example is in the /examples/facebook directory of the extracted download. The code example snippets shown below are taken from the Facebook login example.
+In brief, here are the steps for JavaScript. You can see these steps implemented in the Facebook login example packaged with the JavaScript SDK for Usergrid (which you can download in ZIP format or tar.gz format). The Facebook login example is in the /examples/facebook directory of the extracted download. The code example snippets shown below are taken from the Facebook login example.
### Step 1: Create a Facebook app
Create a new app on the Facebook App Dashboard. Enter your app's basic information. Once created, note the app ID shown at the top of the dashboard page.
@@ -118,11 +118,11 @@ Here is how ``FB.login()`` is implemented in the Facebook login example:
})
}
-The ``client.loginFacebook()`` function is provided by the App Services JavaScript SDK. It uses the Facebook auth token to obtain an App Services auth token. If the Facebook access token is valid and the user does not already exist in App Services, the function creates a user entity for the user. It also uses the Facebook access token to retrieve the user's profile information from Facebook.
+The ``client.loginFacebook()`` function is provided by the Usergrid JavaScript SDK. It uses the Facebook auth token to obtain an Usergrid auth token. If the Facebook access token is valid and the user does not already exist in Usergrid, the function creates a user entity for the user. It also uses the Facebook access token to retrieve the user's profile information from Facebook.
Here is what the ``client.loginFacebook()`` function looks like:
- Apigee.Client.prototype.loginFacebook = function (facebookToken, callback) {
+ Usergrid.Client.prototype.loginFacebook = function (facebookToken, callback) {
var self = this;
var options = {
method:'GET',
@@ -136,7 +136,7 @@ Here is what the ``client.loginFacebook()`` function looks like:
if (err && self.logging) {
console.log('error trying to log user in');
} else {
- user = new Apigee.Entity('users', data.user);
+ user = new Usergrid.Entity('users', data.user);
self.setToken(data.access_token);
}
if (typeof(callback) === 'function') {
@@ -145,11 +145,11 @@ Here is what the ``client.loginFacebook()`` function looks like:
});
}
-Notice that the function also returns an App Services access token, which you can use for subsequent App Services API calls.
+Notice that the function also returns an Usergrid access token, which you can use for subsequent Usergrid API calls.
-Remember to create a client for your app, which is the main entry point to the JavaScript SDK for App Services. You need to do this before you can use the SDK. Here’s the code to create a client:
+Remember to create a client for your app, which is the main entry point to the JavaScript SDK for Usergrid. You need to do this before you can use the SDK. Here’s the code to create a client:
- var client = new Apigee.Client({
+ var client = new Usergrid.Client({
orgName:'yourorgname',
appName:'yourappname',
logging: true, //optional - turn on logging, off by default
http://git-wip-us.apache.org/repos/asf/incubator-usergrid/blob/acae9591/docs/security-and-auth/revoking-tokens-logout.md
----------------------------------------------------------------------
diff --git a/docs/security-and-auth/revoking-tokens-logout.md b/docs/security-and-auth/revoking-tokens-logout.md
index ffbadcb..386f04f 100644
--- a/docs/security-and-auth/revoking-tokens-logout.md
+++ b/docs/security-and-auth/revoking-tokens-logout.md
@@ -3,7 +3,7 @@
Under certain circumstances, you may need to explicitly revoke one or more tokens associated with a user entity, such as when a user logs out of your app. This is accomplished by making a PUT request to the /revoketoken and /revoketokens endpoints.
## Revoking tokens (user logout)
-If a user has been logged in using the Apigee iOS, Android, JavaScript or node.JS SDKs, the returned token is automatically stored in the ApigeeDataClient (iOS), DataClient (Android), Apigee.Client (JavaScript), Usergrid.Client (node.JS) class instance. Calling the logout method of the SDK will destroy the token on the server, as well as in the client object.
+If a user has been logged in using the Usergrid iOS, Android, JavaScript or node.JS SDKs, the returned token is automatically stored in the UsergridDataClient (iOS), DataClient (Android), Usergrid.Client (JavaScript), Usergrid.Client (node.JS) class instance. Calling the logout method of the SDK will destroy the token on the server, as well as in the client object.
### Request syntax
http://git-wip-us.apache.org/repos/asf/incubator-usergrid/blob/acae9591/docs/security-and-auth/securing-your-app.md
----------------------------------------------------------------------
diff --git a/docs/security-and-auth/securing-your-app.md b/docs/security-and-auth/securing-your-app.md
index 7030aef..6eb043f 100644
--- a/docs/security-and-auth/securing-your-app.md
+++ b/docs/security-and-auth/securing-your-app.md
@@ -1,9 +1,9 @@
# Security best practices
-There a number of actions you should take to ensure that your app is secure before you put it into production. The following is not an exhaustive list, but offers some common best practices you should consider following to keep your app secure when using the API BaaS.
+There a number of actions you should take to ensure that your app is secure before you put it into production. The following is not an exhaustive list, but offers some common best practices you should consider following to keep your app secure when using the Usergrid.
## Never use the 'sandbox' for a production app
-By default, every new API BaaS account has an app named “sandbox” that is already created under your new organization. This app is no different than any other app that you might create, except that the Guest role has been given full permissions (that is, /** for GET, POST, PUT, and DELETE). This eliminates the need for a token when making application level calls, and can make it much easier to get your app up and running; however, it also means that any data in the sandbox application is completely unsecured.
+By default, every new Usergrid account has an app named “sandbox” that is already created under your new organization. This app is no different than any other app that you might create, except that the Guest role has been given full permissions (that is, /** for GET, POST, PUT, and DELETE). This eliminates the need for a token when making application level calls, and can make it much easier to get your app up and running; however, it also means that any data in the sandbox application is completely unsecured.
As with any other app, you can secure the sandbox application by updating its roles and permissions. For more on working with permissions and roles, see [Using Permissions](using-permissions.html).
@@ -41,4 +41,4 @@ The client secret-client id combination should be used only in secure, server-si
## Treat mobile clients as untrustworthy
For mobile access, it is recommended that you connect as an application user with configured access control policies. Mobile applications are inherently untrusted because they can be easily examined and even decompiled.
-Any credentials stored in a mobile app should be considered secure only to the Application User level. This means that if you don’t want the user to be able to access or delete data in your API BaaS application, you need to make sure that you don’t enable that capability through roles or permissions. Because most web applications talk to the database using some elevated level of permissions, such as root, it’s generally a good idea for mobile applications to connect with a more restricted set of permissions. For more information on restricting access through permission rules, see [Using Permissions](using-permissions.html).
+Any credentials stored in a mobile app should be considered secure only to the Application User level. This means that if you don’t want the user to be able to access or delete data in your Usergrid application, you need to make sure that you don’t enable that capability through roles or permissions. Because most web applications talk to the database using some elevated level of permissions, such as root, it’s generally a good idea for mobile applications to connect with a more restricted set of permissions. For more information on restricting access through permission rules, see [Using Permissions](using-permissions.html).
http://git-wip-us.apache.org/repos/asf/incubator-usergrid/blob/acae9591/docs/security-and-auth/user-authentication-types.md
----------------------------------------------------------------------
diff --git a/docs/security-and-auth/user-authentication-types.md b/docs/security-and-auth/user-authentication-types.md
index 79e140f..1a14f50 100644
--- a/docs/security-and-auth/user-authentication-types.md
+++ b/docs/security-and-auth/user-authentication-types.md
@@ -1,6 +1,6 @@
# Authentication levels
-App Services supports four levels of authentication, but only one of them is used when checking a registered user's permissions. The other three levels are useful for authenticating other application or web clients that require higher-level access to your App Services application or organization. Because the scope of access that the other authentication levels provide is so broad (and as a result, so powerful), it's a bad practice to use them from a mobile app. Instead, they're better suited to other client apps, such as web applications.
+Usergrid supports four levels of authentication, but only one of them is used when checking a registered user's permissions. The other three levels are useful for authenticating other application or web clients that require higher-level access to your Usergrid application or organization. Because the scope of access that the other authentication levels provide is so broad (and as a result, so powerful), it's a bad practice to use them from a mobile app. Instead, they're better suited to other client apps, such as web applications.
## Configuring authentication levels
Access permissions can only be configured for the 'application user' – this can be done both programmatically and in the admin portal. The application, organization and admin clients cannot be configured, and can only be accessed programmatically via the API.
@@ -16,14 +16,14 @@ For more about creating and managing roles and permissions for application users
</tr>
<tr>
<td>Application user</td>
- <td>This is the standard authentication type you will use to implement user login for your app. The application user level allows access to your App Services application as governed by the permission rules you create and associated with users and user groups. For more on setting permissions see Managing access by defining permission rules. Each Application User is represented by a User entity in your App Services application. For more about the User entity, see User.</td>
+ <td>This is the standard authentication type you will use to implement user login for your app. The application user level allows access to your Usergrid application as governed by the permission rules you create and associated with users and user groups. For more on setting permissions see Managing access by defining permission rules. Each Application User is represented by a User entity in your Usergrid application. For more about the User entity, see User.</td>
</tr>
</table>
## Admin authentication levels
<div class="admonition warning"> <p class="first admonition-title">WARNING</p> <p class="last">
-Warning: Safe use of admin authentication levels. Never use client ID and client secret, or any hard-coded credentials to authenticate this way from a client-side app, such as a mobile app. A hacker could analyze your app and extract the credentials for malicious use even if those credentials are compiled and in binary format. Even when authenticating with username and password, be cautious when using these authentication levels since they grant broad access to your App Services account. See "safe mobile access" in Authenticating API requests for additional considerations in keeping access to your app and its data secure.</p></div>
+Warning: Safe use of admin authentication levels. Never use client ID and client secret, or any hard-coded credentials to authenticate this way from a client-side app, such as a mobile app. A hacker could analyze your app and extract the credentials for malicious use even if those credentials are compiled and in binary format. Even when authenticating with username and password, be cautious when using these authentication levels since they grant broad access to your Usergrid account. See "safe mobile access" in Authenticating API requests for additional considerations in keeping access to your app and its data secure.</p></div>
<table class="usergrid-table">
<tr>
@@ -32,21 +32,21 @@ Warning: Safe use of admin authentication levels. Never use client ID and client
</tr>
<tr>
<td>Application client</td>
- <td>Grants full access to perform any operation on an App Services application (but not other applications within the same organization).
+ <td>Grants full access to perform any operation on an Usergrid application (but not other applications within the same organization).
- <p>Authentication at this level is useful in a server-side application (not a mobile app) that needs access to resources through the App Services API. For example, imagine you created a website that lists every hiking trail in the Rocky Mountains. You would want anyone to be able to view the content, but would not want them to access the App Services API and all your data directly. Instead, you would authenticate as an application client in your server-side code to access the data via the API in order to serve it to your website's visitors.</p></td>
+ <p>Authentication at this level is useful in a server-side application (not a mobile app) that needs access to resources through the Usergrid API. For example, imagine you created a website that lists every hiking trail in the Rocky Mountains. You would want anyone to be able to view the content, but would not want them to access the Usergrid API and all your data directly. Instead, you would authenticate as an application client in your server-side code to access the data via the API in order to serve it to your website's visitors.</p></td>
</tr>
<tr>
<td>Organization client</td>
- <td>Grants full access to perform any operation on an App Services organization.
+ <td>Grants full access to perform any operation on an Usergrid organization.
- <p>This authentication level provides the greatest amount of access to an individual organization, allowing a client to perform any operation on an App Services organization and any applications in that organization. This level of access should be used sparingly and carefully.</p></td>
+ <p>This authentication level provides the greatest amount of access to an individual organization, allowing a client to perform any operation on an Usergrid organization and any applications in that organization. This level of access should be used sparingly and carefully.</p></td>
</tr>
<tr>
<td>Admin user</td>
<td>Allows full access to perform any operation on all organization accounts of which the admin user is a member.
- <p>This authentication level is useful from applications that provide organization-wide administration features. For example, the App Services admin portal uses this level of access because it requires full access to the administration features.</p>
+ <p>This authentication level is useful from applications that provide organization-wide administration features. For example, the Usergrid admin portal uses this level of access because it requires full access to the administration features.</p>
Unless you have a specific need for administrative features, such as to run test scripts that require access to management functionality, you should not use the admin user authentication level.</td>
</tr>
http://git-wip-us.apache.org/repos/asf/incubator-usergrid/blob/acae9591/docs/security-and-auth/using-permissions.md
----------------------------------------------------------------------
diff --git a/docs/security-and-auth/using-permissions.md b/docs/security-and-auth/using-permissions.md
index 092d987..34ec664 100644
--- a/docs/security-and-auth/using-permissions.md
+++ b/docs/security-and-auth/using-permissions.md
@@ -1,9 +1,9 @@
# Using permissions
-Permissions allow you to define user access to perform GET, POST, PUT, or DELETE operations on specific resources. When the user submits a request via your app code to the API BaaS API, the user’s permissions are checked against the resource paths that the user is trying to access. The request succeeds only if access to the resource is allowed by the permission rules you specify.
+Permissions allow you to define user access to perform GET, POST, PUT, or DELETE operations on specific resources. When the user submits a request via your app code to the Usergrid API, the user’s permissions are checked against the resource paths that the user is trying to access. The request succeeds only if access to the resource is allowed by the permission rules you specify.
## Permissions syntax
-In API BaaS, permissions are represented in the following format:
+In Usergrid, permissions are represented in the following format:
<operations>:<resource_path>