Jeton aws s3

Chaque demande non anonyme adressée à S3 doit contenir des informations d’authentification permettant d’établir l’identité du mandataire à l’origine de la demande. Dans REST, cela se fait en plaçant d’abord les en-têtes dans un format canonique, puis en signant les en-têtes à l’aide de votre clé d’accès secrète AWS.

Il y a deux façons d’envoyer votre signature avec une demande. La première consiste à mettre votre ID de clé d’accès AWS et la signature que vous avez calculée dans l’en-tête d’autorisation :

Vous pouvez également envoyer une signature en tant que paramètre de chaîne de requête encodé en URL dans l’URL de la demande. Ceci est utile si vous souhaitez activer un troisième pour accéder à S3 en votre nom sans que vous ayez à proxy pour le transfert de données. Par exemple, si vous souhaitez permettre à un utilisateur de télécharger vos données privées directement à partir de S3, vous pouvez insérer une URL pré-signée dans une page Web avant de la donner à votre utilisateur. La chaîne canonisée que vous signez est la même, sauf que vous remplacez le champ DATE dans la chaîne par un champ Expires qui indique quand vous souhaitez que la signature expire. Le champ Expires est indiqué sous la forme du nombre de secondes écoulées depuis l’heure de l’époque et est également inclus en tant que paramètre de chaîne de requête avec votre ID de clé d’accès AWS :

Canonicalisation pour Lors de

l’authentification via l’en-tête Authorization, vous créez la chaîne à signer en concaténant le verbe de demande avec les en-têtes canonisés et la ressource ciblée par la demande.

Les en-têtes utilisés pour la signature de la demande sont : content-md5, content-type, date et tout ce qui commence par x-amz-. La chaîne à signer est formée en ajoutant le verbe REST, la valeur content-md5, la valeur content-type, la valeur date, les en-têtes x-amz canonisés (voir recette ci-dessous) et la ressource ; tous séparés par des sauts de ligne. (Si vous ne pouvez pas définir l’en-tête Date, utilisez l’en-tête x-amz-date comme décrit ci-dessous.)

La ressource est le compartiment et la clé (le cas échéant), séparés par un « / ». Si la demande que vous signez concerne une liste de contrôle d’accès ou un fichier torrent, vous devez inclure ?acl ou ?torrent dans la partie ressource de la chaîne canonique. Aucun autre paramètre de chaîne de requête ne doit être inclus, cependant.

Canonisation de l’authentification de la chaîne de requête

Lors de l’authentification via les paramètres de chaîne de requête, vous créez la chaîne à signer en concaténant le verbe de la demande avec les en-têtes canonisés et la ressource ciblée par la demande.

Les en-têtes utilisés pour la signature de la demande sont les mêmes que ceux utilisés pour l’authentification de l’en-tête d’autorisation, sauf que le champ Date est remplacé par le paramètre Expires. Le paramètre Expires est l’heure à laquelle vous souhaitez que la signature expire, spécifiée comme le nombre de secondes depuis l’heure de l’époque.

Ainsi, la chaîne à signer est formée en ajoutant le verbe REST, la valeur content-md5, la valeur content-type, la valeur du paramètre expires, les en-têtes x-amz canonisés (voir la recette ci-dessous) et la ressource, le tout séparé par des sauts de ligne.

La ressource est la même que celle de l’authentification de l’en-tête d’autorisation : le bucket et la clé (le cas échéant), séparés par un '/'. Si la demande que vous signez concerne une liste de contrôle d’accès ou un fichier torrent, vous devez inclure ?acl ou ?torrent dans la partie ressource de la chaîne canonique. Cependant, aucun autre paramètre de chaîne de requête ne doit être inclus.

en-têtes x-amz sont canonisés par :

• Nom d’en-tête

en

• minuscules En-têtes triés par nom d’en-tête

• Les valeurs des en-têtes dont les noms apparaissent plus d’une fois doivent être coupées d’espaces blancs et concaténées avec des séparateurs de virgules pour être conformes à la section 4.2 de la RFC 2616.

• Supprimer les espaces autour des deux-points dans l’en-tête

• Supprimer les sauts de ligne ('\n') dans les lignes de continuation

• Séparer les en-têtes par des sauts de ligne ('\n')

Quelques points importants :

• La chaîne à signe (verbe, en-têtes, ressource) doit être encodé en UTF-8.

• Les valeurs content-type et content-md5 sont facultatives, mais si vous ne les incluez pas, vous devez toujours insérer un saut de ligne à l’endroit où ces valeurs seraient normalement insérées.

• Certaines boîtes à outils peuvent insérer des en-têtes que vous ne connaissez pas auparavant, tels que l’ajout de l’en-tête « Content-Type » lors d’un PUT. Dans la plupart de ces cas, la valeur de l’en-tête inséré reste constante, ce qui vous permet de découvrir les en-têtes manquants à l’aide d’outils tels que Ethereal ou tcpmon.

• Certaines boîtes à outils rendent difficile la définition manuelle de la date. Si vous rencontrez des difficultés pour inclure la valeur de l’en-tête 'Date' dans les en-têtes canonisés, vous pouvez inclure un en-tête 'x-amz-date' avant la canonisation. La valeur de l’en-tête x-amz-date doit être dans l’un des formats RFC 2616 (http://www.ietf.org/rfc/rfc2616.txt). Si S3 voit un en-tête x-amz-date dans la demande, il ignorera l’en-tête Date lors de la validation de la signature de la demande. Si vous incluez l’en-tête x-amz-date, vous devez toujours inclure un caractère de nouvelle ligne dans la chaîne canonisée à l’endroit où la valeur Date serait normalement insérée.

• La valeur de l’en-tête Date ou, le cas échéant, x-amz-date doit spécifier une heure qui ne s’éloigne pas de plus de 15 minutes de l’horloge du serveur Web S3.

• La fonction de hachage pour calculer la signature est HMAC-SHA1 définie dans la RFC 2104 (http://www.ietf.org/rfc/rfc2104.txt), en utilisant votre clé d’accès secrète comme clé.

Authentification REST : Exemple 1

REST Authentification : Exemple 2

Authentification REST Exemple 3 : Exemple d’authentification de chaîne de requête