File document download and access-rules

7
Good morning, I have an issue with downloading FileDocuments and Access Rights. I’m working on an application that serves external users that require access to personal Documents (which is a specialization of System.FileDocument). Company restrictions prohibit us to link the personal Documents to the Administration.Account object. Hence, when the user logs into the application, we create a non-persistent copy of the FileDocuments. When the user downloads a document, a microflow retrieves the persistent FileDocument based on a unique ID and downloads it for the user.   Now the issue: I can’t set Access Rights on the persistent Document, as there is no way to restrict it to '[%CurrentUser%]'. Giving Read rights to the table would allow potential access to the entire database table. I am thinking about creating an additional persistent FileDocument object (e.g. UserDownload, specialization of FileDocument) where the user gets full Read rights to the database table. When downloading a Document, I create a temporary UserDownload object, download it and then Rollback. This way, the table is only used to generate a FileDocument in cache for the user to download.   I don’t feel this is the best solution to my problem, hence the question: is there anyone who can share a best practice on this? Anyone who has dealt with a similar situation before and used a different solution as the one described above?   It would be highly appreciated! Kind regards, Rochus Meijer
asked
2 answers
1

What you could do is create a bucket with all Documents to which no-one has access. A microflow is used to retrieve the Document and creates a copy for the current user and stores it in another entity PersonalDocument, PersonalDocument has an association to the Account entity and thus has access rights. Right after downloading the PersonalDocument you delete it again, that way the link between the user and the Document are never stored.

The only problem i see is that you somehow need to provide the user with a 'key' that he can use to retrieve the PersonalDocument if the user is able to change this key locally then in theory he could brute force access to all documents. 

But if you were to store the key in your database then you would implictly still have a way to link documents to users which you want to avoid in the first place. 

Besides these two options i see no other way to achieve what you want.

answered
0

Hi Rochus,

  You can certainly create another entity called downloadDocument that is a specialization of personalDocument.  Here you could grant read access rights to everyone, then make a copy of this and never commit it.  Therefore there would never be anything in the table that users could see.  You could even add [currentUser] access rules to this entity and then commit it so that the specific user could access all the documents they have downloaded.  You could set the association to current user when you copy this from personalDocument to downloadDocument.  That could work to meet this specific need.

  However if you are looking for a 'best practice' here, I would strongly recommend reconsidering the policy that prevents an account from being associated.  If you set this association and use it to drive security rules, then this is just as secure as creating a new entity and setting a new association I would think.  I know a company policy is probably something that can't easily be changed but I don't think the existence of an association is a security risk when done properly.

answered