User Groups and Access Control

User Groups:

User groups provide a convenient way for you to aggregate users who share a common set of access rules. As these access rule are applied to the group instead of individual users, they are automatically adjusted when a user joins or leaves the group.

User groups also support nesting where one user group can be added inside another. Child user groups inherit access permissions from their parent. This allows you to define a layered access control model with granularity of permissions increasing as you go down the user group hierarchy.

E.g., for a discussion board app, all users in the members group may have create and read access for posts whereas all members of the moderators subgroup may have update and delete access.

Securing user groups

Security of user groups is also managed using access control rules. On the management portal, you can configure which users and user groups are allowed to add or remove members from a group. This prevents unauthorized users from adding themselves to a user group to which they do not have access.

NOTE : Access rules for user groups are only evaluated for api calls made using the client api keys. Using the master api key will not evaluate any access control rules that are setup.

Managing user groups

Once you have the necessary user group hierarchy and access setup via the management portal, you can manage group memberships in your app via the SDK.

Creating and managing user groups

Creation and management of user group hierarchy can only be done via the Appacitive management portal and is not allowed over the REST api or through the SDK.

Managing members

You can add or remove members for a user group via the AddMembersAsync and RemoveMembersAsync methods on the UserGroup helper class.

        // Adding users to a user group
        AppacitiveUserGroup.addUserInBackground(groupNameOrId, usernameOrId, new Callback<Void>() {
            public void success(Void result) {


        // Removing users from a user group
        AppacitiveUserGroup.removeUserInBackground(groupNameOrId, usernameOrId, new Callback<Void>() {
            public void success(Void result) {


System defined user groups

By default, the appacitive platform provides two system defined user groups. These are

  • loggedin : Represents all logged in users. i.e. users with an auth token generated by calling the loginInBackground() method.
  • anonymous : Represents all non-logged in (anonymous) users.

Access Control

Given that each and every request is in the context of some kind of user, the platform then lets you define rules to control the kind of operations that these users can perform. These rules are called Acls.

User Context

Every request that you app makes to the appacitive platform is associated with a user context. This user context is relayed to the backend via the user authentication token sent in the appacitive-user-auth http header. In the absence of this header, the request is assumed to be made under an anonymous user. In case you are using the SDK, all this is automatically setup when a user is logged in.

For create operations, the user in the user context for that operation is set as the owner for the object. Owners have implicit admin access over objects. Ownership cannot be revoked using acls.


Acls are rules associated with an object that define how access to that object will be moderated. Whenever an api call is made, the user context setup for the api call is used to evaluate the acls applicable on the data affected by the operation. Acl rules define whether a user can perform a particular operation on the affected instance.

Contents of an acl rule:

  • sid : Id of the user or usergroup for which access is being defined.
  • type : Type of id (user or usergroup).
  • permission : Permission type indicating if the specific access is allowed or denied. (allow or deny).
  • access : The access being allowed or denied. (create, update, delete, read or manageaccess).

To prevent having to define the same acl for each and every instance, you can define acls for a type. Acls defined at a type level are inherited by all instances of the given type. Instance level acls extend or override those defined for the type.

Acl evaluation

The type based hierarchy for acls implies that there can be multiple acls applicable on any instance at any point of time. The final set of applicable permissions is evaluated based on a combination of all applicable acls using the following guidelines.

  1. The absence of any matching rules for an object imply an implicit deny for the corresponding operation.
  2. To enable access, you need to define an allow rule allowing the particular access.
  3. An explicit deny rule cannot be overridden and will always result in access being denied for the transaction. This means that you should only use an explicit deny in scenarios where you want to absolutely revoke access with any override.

Managing Acls

The code samples below show how you can manage access control rules for an object via the SDK.

Allow access to an object.

You can setup allow access for a user or usergroup via the allowXXXByXXX methods on the AppacitiveObject/ AppacitiveUser/ AppacitiveDevice's accessControl property.

    AppacitiveObject obj = ...;

    // Allow read and update access to a specific user.

    // Allow read and update access to a specific user group.

    // Allow read and update access to all anonymous users

    // Allow manageaccess and delete access to all logged in users

Deny access to an object implicitly

You can deny access to an object, user or device by simply removing any matching allow or deny acls on that object. This is especially useful when, say, such a rule is defined for a type. All instances of this type will be denied access. But you will still retain the ability to override this deny with an explicit allow on a specific instance. You can implicitly deny access for a user or user group via the resetXXXByUser() and resetXXXByUserGroup() methods on the accessControl property of the object, user or device.

    AppacitiveObject obj = ...;

    // Allow read and update access to a specific user.

    // Allow read and update access to a specific user group.

    // Allow read and update access to all anonymous users

    // Allow manageaccess and delete access to all logged in users

Deny access to an object explicitly

Explicitly denying access to objects, users or devices sets up a deny rule for the given user and action on that object, user or device. You should be careful when using this as a deny rule setup for a type cannot be overridden by an allow acl rule at an instance level. You can remove any explicit acl rules for a user or user group via the denyXXXByUser() and denyXXXByUserGroup() methods on the accessControl property of the object/ user/ device.

    AppacitiveObject obj = ...;

    // Allow read and update access to a specific user.

    // Allow read and update access to a specific user group.

    // Allow read and update access to all anonymous users

    // Allow manageaccess and delete access to all logged in users

Supported types

Acls can be defined for all objects, users and devices. On the SDK, you can apply acls on the corresponding AppacitiveObject, AppacitiveUser and AppacitiveDevice types and their sub classes.


Access control rules act naturally as a secondary level filter over and above the queries that you specify from the client side. As a result, search api calls made using client keys vs master keys may return different results as searches made using the master key will not perform the additional acl based filtering.


When using access control for you app, you need to be aware of the following gotchas.

  1. All access type (read, update, manageaccess and delete) are discrete and granting one does not automatically imply the other.
  2. When an object is created, the user available in the user context is automatically set up as the owner of the object. Owners can perform all operations on that object without any acl setup.
  3. Using the master key in the SDK or when making REST api calls will skip all acl evaluation.
For any query or suggestions, feel free to drop an email to