This shows you the differences between two versions of the page.
Both sides previous revision Previous revision Next revision | Previous revision | ||
rootdir_security [2022/08/06 19:32] yves [Accessing secured content] |
rootdir_security [2023/11/21 16:14] (current) chris |
||
---|---|---|---|
Line 1: | Line 1: | ||
===== Security ===== | ===== Security ===== | ||
- | Security is increasingly important. As PMA.core has been deployed in increasingly complex scenarios over the years, its security features have evolved, too. | + | Security is increasingly important. As PMA.core has been deployed in ever-more complex scenarios over the years, its security features have evolved, too. |
Security pertaining to root-directories is situated at two levels: | Security pertaining to root-directories is situated at two levels: | ||
Line 20: | Line 20: | ||
* [[rootdir_s3|S3 storage]] | * [[rootdir_s3|S3 storage]] | ||
* [[rootdir_azure|Azure storage]] | * [[rootdir_azure|Azure storage]] | ||
- | |||
- | === S3 storage === | ||
- | |||
- | PMA.core is one of the few vendors that [[https://www.prweb.com/releases/pathomation_announces_support_for_cloud_storage_and_file_transfer_protocol_ftp_servers/prweb18296771.htm|supports cloud storage natively]]. | ||
- | |||
- | Let's say that you have an S3 bucket and put slides in it: | ||
- | |||
- | {{ ::rootdir_s3_10.png?direct&400 |}} | ||
- | |||
- | To protect access, you should create a dedicated entity that can only access that content. | ||
- | |||
- | {{ ::rootdir_s3_20.png?direct&400 |}} | ||
- | |||
- | You can then create a pair of dedicated access / secret keys for the new entity: | ||
- | |||
- | {{ :rootdir_s3_30.png?direct&400 |}} | ||
- | |||
- | These keys are then used to configure the S3 mounting point at the PMA.core side: | ||
- | |||
- | {{ :rootdir_s3_40.png?direct&400 |}} | ||
- | |||
- | The mounting point only functions when the provided credentials are still active on the S3 storage side. If not, an error message ensues: | ||
- | |||
- | {{ :rootdir_s3_50.png?direct&400 |}} | ||
- | |||
- | If all is well, you can now browse your slides directly from your S3 content. | ||
- | |||
- | {{ :rootdir_s3_60.png?direct&400 |}} | ||
- | |||
- | As of version 3.1, PMA.core also supports IAM AWS Role policies. | ||
- | |||
- | === Azure storage === | ||
- | |||
- | Microsoft Azure has its own protocol, and so we provide a separate mounting point type of it. | ||
- | |||
- | Let's say that you have an Azure container defined and put some slides in it already: | ||
- | |||
- | {{ :rootdir_azure_10.png?direct&400 |}} | ||
- | |||
- | You can convert these credentials in a connectionstring: | ||
- | |||
- | ''%%DefaultEndpointsProtocol=https;AccountName=pathomation;AccountKey=SUPERSECRET;BlobEndpoint=https://pathomation.blob.core.windows.net/;QueueEndpoint=https://pathomation.queue.core.windows.net/;TableEndpoint=https://pathomation.table.core.windows.net/;FileEndpoint=https://pathomation.file.core.windows.net/;%%'' | ||
- | |||
- | This text snippet is then pasted in the connection string field of the mounting point properties: | ||
- | |||
- | {{ :rootdir_azure_20.png?direct&400 |}} | ||
- | |||
- | If all goes well, you can now serve your slides from your Azure storage repositories. | ||
==== Public vs private ==== | ==== Public vs private ==== | ||
- | As you have more [[user_management|users]] and more root-directories, it becomes undesirable that everybody is allowed to see everything. | + | As you grow your number of [[user_management|users]] and root-directories, you might want to change the default setting that everybody is allowed to see everything. |
Therefore, root-directories can be marked "public" or "private": | Therefore, root-directories can be marked "public" or "private": | ||
Line 77: | Line 29: | ||
{{ :rootdir_public_private_switch.png?direct&200 |}} | {{ :rootdir_public_private_switch.png?direct&200 |}} | ||
- | Public root directories are marked "public", it means every user has access to them. They can be accessed by anybody who is a registered user in [[user_management|the PMA.core user repository]]. | + | Public root directories are marked "public", this means every user has access to them. They can be accessed by anybody who is a registered user in [[user_management|the PMA.core user repository]]. |
- | Private root directories are marked "private", it means only select users can see the content. They are only accessible by those who have been explicitly given access to be allowed to access the folder through the directory's [[rootdir_security#access_control_list|access control list]]. | + | Private root directories are marked "private", which means only select users can see the content. Private root dirs are only accessible by those who have been explicitly given access to the folder through the directory's [[rootdir_security#access_control_list|access control list]]. |
==== Access control lists ==== | ==== 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't: Do this by pressing the "Edit access control list" link after you selected the "private" option: | + | Once marked private, you can select which users are allowed to see the content of a given root directory, and which ones aren't: Do this by pressing the "Edit access control list" link after you have selected the "private" option: |
{{ :acl.png?nolink&400 |}} | {{ :acl.png?nolink&400 |}} | ||
Line 91: | Line 43: | ||
{{ :rootdir_acl_20.png?direct&400 |}} | {{ :rootdir_acl_20.png?direct&400 |}} | ||
- | 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. | + | 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. |
{{ :overview.png?nolink&400 |}} | {{ :overview.png?nolink&400 |}} |