rootdir_security
Differences
This shows you the differences between two versions of the page.
| Both sides previous revisionPrevious revisionNext revision | Previous revision | ||
| rootdir_security [2022/02/10 15:36] – [Accessing secured content] yves | rootdir_security [2022/03/14 11:48] (current) – [Public vs private] yves | ||
|---|---|---|---|
| Line 7: | Line 7: | ||
| * Configure public/ | * Configure public/ | ||
| * Configure account credentials to be used when accessing a UNC network resource path | * Configure account credentials to be used when accessing a UNC network resource path | ||
| - | * Prevent users from access mounted content through root directories that they are or are not allowed to do | + | * Prevent |
| * Define Access control lists | * Define Access control lists | ||
| Line 18: | Line 18: | ||
| === Local hard disk entry points === | === Local hard disk entry points === | ||
| - | If you want to expose a local folder on the server' | + | If you want to expose a local folder on the server' |
| {{ : | {{ : | ||
| + | Note that even though the dialog shows impersonation options, you can't use these in a local path reference context. The impersonation properties are reserved for networked content, and if you fill them in, PMA.core tries to interpret your local reference as a network path, and subsequently fails trying to access it. | ||
| + | |||
| + | {{ :: | ||
| + | |||
| + | So when defining local hard disk paths, make sure the impersonation options are left blank. | ||
| === Network storage (UNC paths) === | === Network storage (UNC paths) === | ||
| Line 33: | Line 38: | ||
| {{ : | {{ : | ||
| + | We can enter this as a path for the mounting point, and add the impersionation information for our pma_read user: | ||
| + | |||
| + | {{ : | ||
| + | |||
| + | The mounting point shows up, and you can activate the View slides tab to inspect its content: | ||
| + | |||
| + | {{ : | ||
| + | |||
| + | If the credentials are faulty, an error appears | ||
| === S3 storage === | === S3 storage === | ||
| + | |||
| + | PMA.core is one of the few vendors that [[https:// | ||
| + | |||
| + | Let's say that you have an S3 bucket and put slides in it: | ||
| + | |||
| + | {{ :: | ||
| + | |||
| + | To protect access, you should create a dedicated entity that can only access that content. | ||
| + | |||
| + | {{ :: | ||
| + | |||
| + | You can then create a pair of dedicated access / secret keys for the new entity: | ||
| + | |||
| + | {{ : | ||
| + | |||
| + | These keys are then used to configure the S3 mounting point at the PMA.core side: | ||
| + | |||
| + | {{ : | ||
| + | |||
| + | The mounting point only functions when the provided credentials are still active on the S3 storage side. If not, an error message ensues: | ||
| + | |||
| + | {{ : | ||
| + | |||
| + | If all is well, you can now browse your slides directly from your S3 content. | ||
| + | |||
| + | {{ : | ||
| === Azure storage === | === Azure storage === | ||
| + | Microsoft Azure has its own protocol, and so we provide a separate mounting point type of it. | ||
| - | ==== Public vs private ==== | + | Let's say that you have an Azure container defined and put some slides in it already: |
| - | Public root directories can be accesses by anybody who is a registered user in the PMA.core user repository. | + | {{ : |
| - | Private root directories are only accessible by those who have been explicitly given access to be allowed to access the folder through the directory' | + | You can convert these credentials in a connectionstring: |
| + | '' | ||
| - | ==== Access control lists ==== | + | This text snippet is then pasted in the connection string field of the mounting point properties: |
| - | As you have more users and more root-directories, | + | {{ : |
| + | |||
| + | If all goes well, you can now serve your slides from your Azure storage repositories. | ||
| + | |||
| + | ==== Public vs private ==== | ||
| + | |||
| + | As you have more [[user_management|users]] and more root-directories, | ||
| Therefore, root-directories can be marked " | Therefore, root-directories can be marked " | ||
| - | * Unordered List ItemWhen they are marked " | + | |
| - | * Unordered List ItemWhen they are marked " | + | {{ : |
| + | |||
| + | Public root directories | ||
| + | |||
| + | Private root directories | ||
| + | |||
| + | ==== Access control lists ==== | ||
| Once marked private, you can select what users are allowed to see the content of the root directory, and which ones aren' | Once marked private, you can select what users are allowed to see the content of the root directory, and which ones aren' | ||
| {{ : | {{ : | ||
| + | |||
| + | An interactive overview grid is available via the Root directories management view: | ||
| + | |||
| + | {{ : | ||
| + | |||
| + | As you get even more root-directories and more users, it is useful to get an overview of who has access to what. For that, you can request the ACL report from the root-directories view. | ||
| + | |||
| + | {{ : | ||
| + | |||
| + | The resulting report looks like this: | ||
| + | |||
| + | {{ : | ||
| + | |||
rootdir_security.1644503789.txt.gz · Last modified: by yves
