Tizen is an open source platform residing within the Linux Foundation. It includes an operating system which can run smartphones, tablets, netbooks, onboard devices in smart cars as well as smart TVs. We wanted to see what it would take to integrate a Tizen app with Backendless because the benefits of such integration would be huge. For instance, data can be easily shared between different implementations of an app: a Tizen version of the app can easily communicate with the one running on Android or iOS by the means of Backendless service APIs.
The second app uses the Backendless Geo Service API to store the device’s GPS coordinates in the remote storage. As the device moves around, the app automatically leaves a trail which can be retrieved with the API or managed directly in the Backendless Developer Console:
Our Data Service supports a very flexible security mechanism for restricting access to objects stored in Backendless. Security permissions apply to users and roles. A permission can either grant or reject an operation for a particular asset. In the context of Data Service, the asset is an object which your app can retrieve, update or delete. Permissions can be granted or rejected globally, where they apply to all tables and all objects in the data store. Additionally, every table may have its own permission matrix and owner policy – a special instruction whether object owners can or cannot retrieve/update/delete the objects they ‘own’. Finally, every object has its own Access Control List (ACL) which is a matrix of permissions for the operations applicable specifically to the object:
The security system is multi-layered. For an API call to retrieve, update or delete object(s), the system goes through several where each can trim the scope of the operations. The layered order of the decision making is important and consists of the following:
ObjectACL for the user who makes the call
ObjectACL for user-defined roles assigned to the user who makes the call.
Table permissions for the User account
Table permissions for the user-defined roles
ObjectACL for system roles
Table permissions for system-level roles
Global user-defined roles
Global system roles
“User-defined roles” – roles created by the application developer
“System roles” – roles built into Backendless (Authenticated User, NonAuthenticated User, SocialUser, etc)
Consider the following guide which illustrates the decision making process:
Backend receives an API request to load data from a table (the Find operation). All objects become candidates for the retrieval. Backendless goes through the security permissions chain to determine which ones must be included.
ObjectACL for the user who makes the call. Backendless checks if there are any restrictions for the user account at the object level. Any object in the collection with ACL which rejects access to the user is excluded from the result. To see or modify the permissions for a particular object, click the ‘key’ icon in the ACL column in the data browser in management console.
ObjectACL for user-defined roles assigned to the user who makes the call. This is the same check as the one above, except Backendless looks into the permissions for the roles defined by the application developer. If the user belongs to any of the custom roles, Backendless checks if these roles are allowed to perform the current operation. In the screenshot below, only the “MyRole” role will be checked in this step, since this is the only custom role in the application:
Table permissions for the User account. Every table in Backendless may have its own set of permissions for users and roles. At this point Backendless checks if the currently logged in user is allowed to run the current operation. For example, if the Find operation is denied for the user, no objects would be returned.
Table permissions for the user-defined roles. This step is identical to the one described above with the exception that is checks custom roles for the table. Since this guide reviews the decision making process for the Find operation, Backendless checks the column for Find. If any of the custom roles deny access, the operation is rejected and no data is returned.
Owner Policy. When a new object is created in Backendless, the system automatically links it with the account of the currently logged in user. You can see that information in the ‘ownerId’ column in any of your tables in the data browser. With the association between objects and users, Backendless provides a way to control whether users can get access to the data they created. This is done through a concept we call ‘Owner Policy’. The policy is available on the ‘Schema and Permissions’ screen. Select a table in the data browser and click the ‘Table Schema and Permissions’ button in the upper right corner. Select the ‘Owner Policy’ menu item. Owner policy can be global (select ‘All Tables’ from the drop down in the upper right corner) or it could apply to a specific table.
Granting a permission for an operation in Owner Policy, guarantees that the objects owned by the current user will be included in the resulting collection. Denying a permission, takes out the ‘owned’ objects from the collection of candidate objects to return. Consider the following:
Granting Find permission in Owner Policy: Results in the following. The objects with bold border are guaranteed to be returned. All other objects will be subject to the subsequent permission checks.
However, if the Owner Policy rejects a permission: The objects owned by the current user will be excluded from the resulting collection. All remaining objects will be decided by the subsequent permission checks.
Object ACL for system roles. This check is identical to step 3 (Object ACL for custom roles). The difference is the system roles cover larger groups of users. For example, this step would make possible to restrict access to specific objects for all authenticated (or not authenticated) users, yet the object would be returned with a query made by the object’s owner if the Owner Policy (previous step) grants access.
Table permissions for system roles. Identical to step 5, this checks if any of the system roles reject the operation at the table level.
Global custom roles. Global policy applies to all tables and objects. By default all table level permissions inherit from the global policy. You can configure in the console at: Users > Security and Permissions. Create a new role and click it to configure the permission matrix:
Global system roles. This is the same as the step above, but checks the built-in system roles (AuthenticatedUser, NonAuthenticatedUser, SocialUser, FacebookUser, TwitterUser).
As you can see the system is very rich and could get very complex. We plan to post a few scenarios showing how to configure the system. If you can think of any scenarios, post them in the comments and we will be happy to show how to handle it with Backendless.
It is hard to believe January is already over. We will remember this month as one filled with a lot of hard work, implementing cool features and fixing some interesting bugs. All of this came to fruition today since we pushed a new release out of the door. To sum the release up with just one word, it would be called “awesome”. Here’s a brief summary of what you will find now in Backendless:
Object Access Control List (ACL)
Any time you save an object in Backendless using the Data Service, we automatically assign the ‘owner’ to the object (assuming there is a currently logged in user). Having an association between a user and the objects he created is helpful since it makes it so much easier for a user to retrieve only the objects he owns. Along with the support for Object ACL, we have greatly enhanced the system of permissions for objects and tables. In fact, the system is so flexible that you can configure any kind of scenario for secure data access (load only objects one created, load only objects which were created anonymously, load only objects which belong to users in specific roles, etc). There will be a detailed blog post with the detailed information about Object ACL.
Being able to control access to files and folders stored in the Backendless File Service has been one of the most requested features. The wait is finally over. With today’s release you can control access to any file and folder using the same intuitive interface we have for other services. The File Browser interface now includes the “Edit Permissions” link for every single item. Clicking the link you can easily adjust the permission matrix for any user or role in the system.
The File Service received quite a makeover in today’s release. In addition to File Permissions, we also added Git integration. Once Git is enabled (you can do it from the Manage > App Settings screen), you can work with your file storage as a git repository. This may be particularly helpful for deploying multiple files or syncing between your local development environment and Backendless file system.
We are very excited about this release. There is a lot more that went into it than just these features – most importantly our passion and love for beautifully made software. We have a feature packed roadmap and can’t wait to get some amazing functionality into your hands. We hope you enjoy using it as much as we did designing and coding Backendless.
One of the coolest features included into our November release is support for mobile audio/video conferencing, screen and gesture sharing. This functionality is made possible through our partnership with ShowKit – a mobile SDK for iOS and other environments. Integration with Backendless makes it trivially easy to enable the users of your mobile app to conference with each other and share app screens. Complete documentation describing the integration is available in the Backendless Media Service API doc as well as ShowKit’s website.
How much does it cost? Is it free to use? What can I get for free? What are the limitations? How much will it cost as the application grows? These are all very reasonable questions. When you decide to use a backend-as-a-service system, you should definitely estimate your usage and see what you may end up spending over time. The good thing is with Backendless the API usage is unlimited – your application can make unlimited number of API calls and we will not charge you for that. There is only one plan with Backendless and it is free. The plan has some limits for the number of resources included into it. Once you go over the limits, you would pay only for what you use. The video below provides an overview of our plan. For additional information about the pricing, see the Backendless Pricing page.
Free Plan in Backendless
In this video we discuss the subscription plan available from Backendless and review the pricing options. Backendless Online Service comes with a generous Free plan. The plan has no functional limitations, it means that all the features of Backendless are fully available with the Free plan.