Best practice to time limited access / security concern

[DataCruncher]

Hello everybody, 

 

We have been using SuperContainer for years - with good results - but I am hitting a roadblock now and was wondering if some of you could chime in with best practice suggestions as to how to time limit access to certain SuperContainer paths. 

 

Security for SuperContainer is nested within the folder path - know the path, get access. I know all the arguments for and against, but it has been accepted practice to handle access that way, the theory being that a long folder path essentially equals a username/password combination. 

 

There is one big drawback, though: A username/password can be revoked, or a password changed. 

 

If a database system in FileMaker uses SuperContainer though, chances are the SuperContainer file path is also used for a million other things other than controlling access. 

 

In a use case, an employee who used to work on a web solution referencing super container files gets their access privileges revoked. However, their browser history will continue to contain all the SuperContainer file paths, and they will not change just because one user account was suspended. In fact, currently, I have zero relation between user account and SC File path. 

 

What is best practice there? I need a way to tie access to a SuperContainer file to a user account. .htpasswd would not work as I can't pass credentials in a URL - that would result in the same problem as the credentials would persist in the browser history and even worse would be accessible. 

 

Happy for any piece of advice. I was thinking of moving the folder path to a different one on the NFS but that would be next to impossible to manage and how do I ensure the changes in folder path remain in sync with the reference database in Filemaker?

 

Not sure what the best approach is to secure SuperContainer in a way that allows me to yank access as I please. 

 

Thank you!

 

 

[DataCruncher]

Hello everyone!

 

I am surprised no one seems to have any thoughts on this. 

 

Once anyone knows a SuperContainer URL, they can simply save it in their browser history. Once they get terminated, they still have access! How is that acceptable practice. Here are my thoughts on how to secure access: 

 

1) work with an alias file path on NFS level. I have not tried that yet. But the idea would be to have a permanent NFS file path to the SuperContainer location; and then a temporary alias pointing to that path - but the file path alias gets revoked once the user is done with that file. The user never knows what the permanent file path is.  

What I don't know is whether SuperContainer would work with alias paths instead of hard file paths? 

 

2) Similar concept to 1); but instead of file path aliases, move (or copy) files from temporary paths to secure permanent ones. This spells nothing but trouble - break in systems, one goes down, everything fails. 

 

3) Dynamic root path for Filemaker. Simply use a cronjob with a formula to calculate the FileMaker root path for that day; if you know todays URL, nothing will be there tomorrow unless you know how the temp root path is calculated. 

 

None of these ideas seem ideal. What have others done to address the concern of permanent access with permanent SuperContainer URLs? 

 

Am I missing something here? 

 

Thank you!!