Hi - Can you please help with below quick doubts about ‘security and roles’ ?
-
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 ?
-
Does ‘owner policy’ have highest priority - so, if GRANT as per owner policy, but DENY as per ‘asset permission’ - which will apply ??
Thanks.
I am still a bit confused on (1) above - can you plz confirm if my understanding in below scenario is correct.
Scenario:
- An android app user, have done login (using, Backendless.UserService.login) with user defined role - say, Merchant.
- A jar is created and uploaded for a hosted API service with an exposed API (say, fetchSettings) .
- 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 :
- 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.