Quick doubts about security and roles ??

Hi - Can you please help with below quick doubts about ‘security and roles’ ?

  1. What role does ‘backend API’ operations assume, if -
    a) called externally as REST API ?
    b) called by a already logged in app user, using generated SDK ?

  2. Does ‘owner policy’ have highest priority - so, if GRANT as per owner policy, but DENY as per ‘asset permission’ - which will apply ??

Thanks.

(1) See the documentation at:

https://backendless.com/documentation/users/ios/users_user_roles.htm

(2) You can see the priority order of Owner Policy at:
https://backendless.com/documentation/data/ios/data_security.htm

I am still a bit confused on (1) above - can you plz confirm if my understanding in below scenario is correct.

Scenario:

  1. An android app user, have done login (using, Backendless.UserService.login) with user defined role - say, Merchant.
  2. A jar is created and uploaded for a hosted API service with an exposed API (say, fetchSettings) .
  3. Within the hosted API (fetchSettings) - say it queries a table ‘Settings’.

Now, if ‘fetchSettings API’ is called by this android user, using ‘Backendless.CustomService.invoke’ - will all of following 4 roles will apply to this query - AndroidUser | AuthenticatedUser | Merchant | ServerCodeUser ??

Thanks.

Now, if 'fetchSettings API' is called by this android user, using 'Backendless.CustomService.invoke' - will all of following 4 roles will apply to this query - AndroidUser | AuthenticatedUser | Merchant | ServerCodeUser ??

Are you talking about the query to the “Settings” table?

YES, query to the ‘settings’ table - but made by the ‘hosted API service’ (and not directly by android user) i.e. called by android app (with user with role = Merchant logged in).

That request will have the following roles: ServiceCodeUser and NotAuthenticatedUser. The reason for this is because server-side code does not assume any identity by default.

So, you mean that the identity of the logged in user DOES NOT get passed automatically - on calling hosted service API with SDK (Backendless.CustomService.invoke) ?

Wont this a kind of security loop hole - cause this means, I cannot DENY operations to ‘NotAuthenticatedUser’ - if I do so, no operations from server side code will work !!!

(as they will get rejected at step 7 or 9 here - https://backendless.com/documentation/data/android/data_security.htm)

So, you mean that the identity of the logged in user DOES NOT get passed automatically - on calling hosted service API with SDK (Backendless.CustomService.invoke) ?

Identify of the user who made the call is not passed BY DEFAULT. That’s what I mean. However, both userToken and userId of the user who made the call are provided to you via the InvocationContext class:
https://backendless.com/documentation/api-engine/apieng_invocation_context.htm

You can set the userToken before your service uses the API and the original user identity will be passed on. The code to set userToken is:

HeadersManager.getInstance().addHeader( HeadersManager.HeadersEnum.USER_TOKEN_KEY, userToken );

Ok, got it - and in the server code, do I need to call any api again ? or backend will take it itself from invocation_context ??

Hi Mark - I also one very basic doubt :

  1. As per this link - the not rejected objects move down to subsequent permission checks - so this means if I want to GRANT access to a particular data table to only 1 out of 5 user defined roles - then I will have to do below:
    i) GRANT for AuthenticatedUser
    ii) DENY for all 4 roles - and let remaining 1 role inherit.

But, looking at your this file access video (https://www.youtube.com/watch?v=F0nvORx4oVs) - it seems that it can work other way round too - so :

i) DENY to AuthenticatedUser, and
ii) GRANT to 1 particular user defined role.

But this goes against, what you mentioned on ‘Data security’ page - "the system goes through several where each can trim the scope of the operations. "

Is the concept different for ‘data’ and ‘files’ ?

What I wrote applies only to server-code…

If any of the roles present in the context of a given invocation has DENY, the invocation will be denied.

That’s what I understood too - but your file acces video (https://www.youtube.com/watch?v=F0nvORx4oVs) - is doing otherwise.

You did DENY for ‘AuthenticatedUser’ (and GRANT to particular user) - but you were still able to access file - anyways, its not of immediate importance.

Thanks.

That’s because “Owner policy” has higher order than “Table permissions for system level roles” in this hierarchy (see the 9 elements hierarchy):

https://backendless.com/documentation/data/android/data_security.htm

Yes, but you video refers about ‘files’ and not ‘data’ - I believe files have no owner policy.