The Pylomer API platform security picture consists of two main parts: authentication and authorization. Authentication means validating the identity of the user. Authorization means controlling what operations the user is able to perform. Operations consist of creating, reading, updating and deleting records from the system.


The centerpiece of the Pylomer API platform consists of industrial-strength authentication provided as part of the Google App Engine platform. By default, all access is restricted to known users with valid Gmail addresses. Only requests containing valid authentication (OAuth2) credentials provided by Google are processed. When an unathenticated user attempts to access the system, he or she is directed to a Google login screen. You can rest assured that any and all unknown users will be denied access to your application and its data.


The second part of the auth picture involves authorization. An authenticated user typically has access, or authorization, only to a specific set of entities or records, specific attributes of them or specific operations on them.

Any serious authorization scheme involves Role-Based Access Control (RBAC). RBAC greatly simplifies the problem of determining what a user can do on a system. RBAC specifies that the user of a system is assigned one or more roles. A role has specific permissions in a given context. Entities and operations on entities are associated with required permissions. A user with a given role can perform only the operations allowed to that role by the entity being accessed.

Applications implementing simpler, non-RBAC authorization schemes often contain authentication logic scattered thoughout an application. For anything but the simplest of use cases this is to be avoided as it is error prone and difficult to understand and maintain. While being simple to understand and maintain, the Pylomer API platform’s RBAC scheme provides a great deal of flexibility.


The Pylomer API platform currently provides two roles: admin and user. These are implemented in the software as lists of user IDs for each role. It provides two levels of permissions, also user and owner, which are implemented in the system as rules associated with operations such as view, update and delete within the context of an entity.

These roles and permissions exist because the entities in the system can be cleanly divided into two main types: those created by admininstrators and necessary to the functioning of the system, and those created by users in normal, daily operations.

Admin role

The admin role has authorization to create, modify and delete entities essential to the proper functioning of the system and visible to all users. An example might be a manager adding a product to the inventory at a retail store.

User role

The role associated with most of the normal, day-to-day activity in the system. For example, adding a sale to the list of daily transactions.


Permissions are specified by means of specifying a required role to for an entity kind or operation. This has the effect of limiting access to users having the designated role.

Admin permissions

Entities having importance to the functioning of the system are designated with admin permissions. Only users granted the admin role may modify or delete an entity so designated.

User permissions

Entities created by users are by default designated with user permissions. An entity so designated may be viewed, modifed or deleted only by the owner of the entity. Configuring authorization Authorization settings are contained in the file auth.yaml. The structure of the file is fairly simple. This might be the auth.yaml for a simple trading API such as eBay:

 ShippingOptions: admin
 Listings: user
 - Ed.Harris
 - Mary.Matrantonio
 - J.C.Quinn
 - Leo.Burmester
 - Kimberly.Scott

Notice the two top-level sections: permissions and roles. The admin role is specified for ShippingOptions. The user role is specified for Listings. Two people have the admin role, and three have the user role. Adding and removing permissions and roles are just a matter of modifying and uploading this file to the App Engine platform. The resulting changes go into effect immediately.

With these settings, users Ed and Mary may add, modify and delete ShippingOptions, while J.C., Leo and Kimberly may add, modify and delete Listings. By default, a user may view only his own Listings, but this can be customized. Finer-grained configuration is possible in service-level logic for entity types (Kinds) and method-level logic for specific operations (GET, PUT, POST, DELETE). However, with more complex rules, there is greater opportunity for mistakes. The Pylomer API platform is not designed to accommodate complex organizational structures such as enterprise-grade platforms can. Simplicity is the keyword for predictable access control.

App Engine authorization

This is a separate set of authorizations related to the management of the App Engine platform, including the selection and deployment of application versions. Google’s Identity and Access Management (IAM) can be used to tailor more sophisticated authorization schemes. More information can be found in the App Engine and Google Cloud documentation.

More on authorization

The upshot of all this is that authorization and security is a large and complex subject. In the interest of simplicity, the options in the Pylomer API platform are limited to a rather small subset of those needed for an enterprise-class content management system. Yet the fundamentals of RBAC have been implemented and thus greatly decrease the cost of managing access control over more rudimentary methods such controlling access solely by means of logic spread throughout the application. Managing roles and permissions is mostly quite straightforward and requires no programming knowledge and involves simply uploading a text file to the deployed application. The absence of web-based access control greatly limits exposure to intruders.