Authentication of users and access to data based on S3 keys provided through Run-time Substitution.

[MathewNWSH]

Expected behavior.

Hello,

During my work with MapServer, I made an interesting observation regarding the use of runtime substitution in MAP->CONFIG. Specifically, users could dynamically choose a pair of S3 keys they want to use via the URL. It would look something like this:

MAP
  NAME "Results of crop prediction"

  CONFIG "AWS_S3_ENDPOINT" "some.endpoint.com"
  CONFIG "AWS_ACCESS_KEY_ID" "%s3_access%"
  CONFIG "AWS_SECRET_ACCESS_KEY" "%s3_secret%"
...

The s3_access and s3_secret would be provided in the following way:
.../wms.map&s3_access=...&s3_secret=...

This way, users with private S3 buckets could share their service only with individuals possessing the complete set of S3 keys. Additionally, this could serve as a method of authentication and monitoring the usage of WMS based on S3 credentials.

Of course, certification would be needed for securely sharing keys using HTML. However, it seems to be a very interesting option with a lot of possibilities.

The current status of runtime substitution allows the functionality to be used in followed parameters:
(no support of MAP->CONFIG)

Operating system / MapServer version and installation method

Ubuntu 22.04; Docker Mapserver 8.0.1

[j-musial]

Are there any updates? S3 protocol is widely used now to stream data from bucket/object storage, so it would be highly usable if the S3 credentials could be substituted in the MAP file.

[rouault]

Putting S3 credentials in URL seem like a bad idea from a security point of view... Probably that a signed URL or other mechanisms not requiring sharing the base credentials would be much better

[j-musial]

It depends what type of S3 keys are to be provided. The read-only S3 keys are not much different from the signed URLs. They may also have an eviction time defined so what would be the difference? It would be up to the user to provide a correctly secured S3 keys.