amazon-s3 - servidor - storage s3 aws

¿Admite Amazon S3 la solicitud HTTP con autenticación básica?

Question

Me gustaría configurar una cuenta de Amazon S3, crear un depósito, cargar algunos datos y que estos datos estarán disponibles mediante HTTP GET con autenticación básica .

Sé que hay varias maneras de autenticar los datos S3 (cadena de consulta y demás), pero me gustaría poder proporcionar un esquema simple de nombre de usuario / contraseña para la autenticación.

es posible?

Answer 1

Al poner en capas varios servicios de AWS, puede lograr algo cercano a la Autorización HTTP básica.

1. Crea un sitio estático s3.
2. Cree una distribución de CloudFront para servir el sitio estático de s3 (use la url de sitio estática y no el nombre de depósito)
3. Use AWS WAF para crear una regla que solo permita solicitudes con el encabezado de Autorización http correcto. Esta será una regla de concordancia en el contenido del encabezado Autorización.
4. Use Route53 para enrutar un dominio personalizado a la distribución de CloudFront

Ahora debería tener un sitio estático al que solo se puede acceder con el nombre de usuario y la contraseña correctos.

NOTA: al utilizar esta configuración, no se le solicitarán sus credenciales, ya que la solicitud se bloquea con un 403 Prohibido en lugar de 401 No autorizado .

NOTA: Puede crear una distribución de CloudFront directamente frente a un depósito de s3, pero no podrá establecer de forma predeterminada un archivo de índice raíz en las subcarpetas.

Answer 2

Eche un vistazo a mi respuesta aquí en esta pregunta algo relacionada.

La pregunta era para obtener una LISTA de objetos compartidos sin necesidad de una gran autenticación de inicio de sesión S3. Entonces, por su pregunta, mi respuesta realmente no explica su consulta para Http-request with basic username/password authentication , sino que ofrece la posibilidad de hacer que el depósito sea privado y aún así recuperar sus datos sabiendo un grupo de identity-pool (ID) y un Amazon Resource Name (ARN) (que puede considerar similar al nombre de usuario y la contraseña). Por supuesto, para obtener el (ID) y (ARN) tiene que hacer algunas configuraciones -trabajar en las páginas principales de AWS como se describe en mi respuesta de 17 pasos aquí ... - y también, no es parte del OBJETIVO- solicitud, sino más bien dentro del marco AWSS3 que proporciona Amazon. Espero, todavía te da más opciones para tu pregunta;)

Answer 3

Esto ahora es posible usando CloudFront y Lambda @ Edge (generalmente disponible desde julio de 2017 en la región de US-east-1).

1. Crea un cubo S3
2. Configure una distribución de CloudFront al frente del depósito, restringiendo el acceso al depósito para que solo CloudFront pueda acceder a él directamente
3. Cree una función Lambda, que imitará el protocolo de enlace HTTP Auth con el navegador. Asignarlo al comportamiento de CloudFront Viewer Request .

Aquí está la función Lambda: https://gist.github.com/lmakarov/e5984ec16a76548ff2b278c06027f1a4

Aquí hay un artículo con más detalles: https://medium.com/@lmakarov/serverless-password-protecting-a-static-website-in-an-aws-s3-bucket-bfaaa01b8666

Answer 4

La respuesta corta es no, no usa autenticación básica. Pero aquí hay una manera que es efectivamente igual a la autenticación básica, y eso es más fácil que otras soluciones enumeradas. Creo que es seguro, pero no estoy seguro.

Puede establecer condiciones en los depósitos s3 que coincidan con los encabezados de la solicitud. Como ejemplo, puede usar los encabezados useragent y referer como algo equivalente al nombre de usuario y la contraseña en la autenticación básica. Normalmente el agente de utilización es el navegador y el sistema operativo (como Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:47.0) Gecko/20100101 Firefox/47.0) , y el referer es la página web anterior.

Aquí hay un ejemplo de política de cubo s3 que permite colocar objetos y obtener objetos haciendo coincidir el agente de uso y el referer (cambiar nota: BUCKETNAME , USERNAME , PASSWORD , AWS_REGION y FILENAME a sus detalles):

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "allow-username-and-password-access",
            "Effect": "Allow",
            "Principal": {
                "AWS": "*"
            },
            "Action": [
                "s3:PutObject",
                "s3:GetObject"
            ],
            "Resource": "arn:aws:s3:::BUCKETNAME/*",
            "Condition": {
                "StringEquals": {
                    "aws:UserAgent": "USERNAME",
                    "aws:Referer": "PASSWORD"
                }
            }
        }
    ]
}

Para poner un recurso en el depósito, puede usar una solicitud de curl como esta (cambio de nota: BUCKETNAME , USERNAME , PASSWORD , AWS_REGION y FILENAME ):

curl --user-agent USERNAME --referer PASSWORD --upload-file "FILENAME" --request PUT "https://s3-AWS_REGION.amazonaws.com/BUCKETNAME/FILENAME"

Para utilizar el recurso puedes usar algo como esto:

curl --user-agent USERNAME --referer PASSWORD "https://s3-AWS_REGION.amazonaws.com/BUCKETNAME/FILENAME" > FILENAME

Una vez más, creo que esto es seguro, ya que el agente de utilización y el remitente deberían estar encriptados si usa https, pero dígame si no lo está.

Answer 5

No, esto no es posible. Debes conformarte con la API de Autenticación de Amazonas

Eche un vistazo a algunas de las envolturas que figuran here .

Answer 6

Puede desarrollarlo usted mismo como una aplicación web o como parte de su aplicación existente. Consumirá las solicitudes HTTP, recuperará su componente URI, lo convertirá en nombre de objeto S3 y usará getObject() para obtener su contenido (usando uno de los SDK S3 disponibles, por ejemplo AWS Java SDK ).

De lo contrario, puede probar una solución alojada: s3auth (soy desarrollador). Es un proyecto de código abierto, y puede ver cómo este mecanismo se implementa internamente en una de sus clases principales . El servicio procesa la solicitud HTTP y luego la vuelve a traducir al esquema de autenticación interna de Amazon S3:

http://s3auth:[email protected]/texry/packages.png

Este diagrama de arquitectura explica cómo se implementa el proyecto. La imagen PNG se carga desde el cubo de Amazon S3 maven.s3auth.com , que no se puede leer de forma anónima. La URL completa de esta imagen es

http://s3auth:[email protected]/texry/packages.png

Consulte también este artículo: autenticación HTTP básica para cubos S3

Answer 7

Soy de AdroitLogic. Acerca del artículo vinculado, muestra cómo el UltraESB podría colocarse entre su cliente y Amazon S3 para autenticar sus solicitudes. Si es necesario, podría crear un servicio "proxy" que aceptará la autenticación básica de su cliente y enviará las credenciales de la forma que Amazon S3 espera. Esto podría hacerse de manera trivial y ocultará cualquier complejidad para su cliente.

Answer 8

Yo mismo estaba tratando de encontrar una solución a este problema. https://medium.com/@lmakarov/serverless-password-protecting-a-static-website-in-an-aws-s3-bucket-bfaaa01b8666 publicación aquí los ha enumerado todos. Citando las líneas:

He estado buscando durante meses una solución para agregar la Autenticación HTTP básica a los segmentos S3 en Amazon. Hay opciones que involucran URL pre-firmadas (solo un objeto), usando un servicio comercial o gratuito de terceros (cuestiones de privacidad), girando un EC2 / Heroku / etc. con middleware para solicitudes de proxy (complicado y no sin servidor), utilizando redireccionamientos de página y políticas de segmento (no seguro).

Solución de políticas de cubo: lo he intentado personalmente y me parece perfectamente seguro (a menos que tenga una forma de eludir las políticas de bucket de aws). Solo requiere que s3 bucket funcione. Simple de implementar. Idea básica:

1. Restrinja el acceso a todo el sitio, excepto permitir el acceso público a Entry File y Secret File.
2. Archivo de entrada secure.html que acepta una entrada de usuario para la contraseña y redirecciones a Archivo secreto
3. Secret File thisisasecret que redirige a Main File (index.html) que alberga el contenido real del sitio
4. Main File main.html que solo permite el acceso a solicitudes originadas desde el mismo sitio.
5. Todos los demás contenidos, como los archivos css, js, estarían restringidos por una política de depósito que les permitirá atenderse si la solicitud se originó en la URL de su depósito.

Uso de aws Lambda @ Edge: esta solución requiere s3, aws lambda y aws cloudfront para operar. Idea básica:

1. Crea un secure.html . Cree cuadros de texto para ingresar credenciales básicas del usuario aquí. Este archivo debe ser de acceso público y debe llamar a una función lambda.
2. Al configurar Cloudfront crea un comportamiento que dice "si quieres llegar a index.html, debes hacerlo a través de la URL firmada".
3. Al igual que arriba, cree una política de depósito para permitir el acceso a los archivos js, css, etc. solo cuando el origen sea su URL de depósito.