Как обслуживать клиентский запрос для хранилища BLOB-объектов после ротации ключей в Azure

У меня есть хранилище BLOB-объектов с некоторыми ресурсами. Я предоставляю клиентам токены SAS, и каждый токен создается только для конкретного большого двоичного объекта клиенту. По прошествии некоторого времени я хочу поменять ключи своей учетной записи, таким образом, все токены фактических клиентов будут аннулированы (у клиентов нет ключа учетной записи, у них есть только токен).

Мне было интересно, есть ли у кого-то похожий случай, когда при использовании REST API для службы хранилища Azure необходимо предоставлять новые токены SAS клиентам после ротации ключей. Я знаю, что в этой ситуации клиент получит сообщение 403 Unauthorize, поэтому один из вариантов - отправить еще один запрос на новый токен, а затем повторить запрос ресурса.

Или, может быть, я мог бы отправить обратно 301 перемещенный http-код и ссылку для конечной точки REST, которая восстанавливает новый токен, поэтому клиенту не нужно будет иметь дополнительные сведения о другой конечной точке.

Есть ли у кого-нибудь такой опыт ротации токенов?


person Kamil Z    schedule 04.07.2019    source источник
comment
Ваши пользователи получают доступ к большим двоичным объектам напрямую с помощью URL-адреса SAS (например, получают URL-адрес SAS и вставляют его в браузер) или они заходят в ваше приложение? Если это раньше, то вы действительно ничего не можете сделать, так как вы не узнаете, выдал ли URL-адрес SAS ошибку 403. Если последнее, то зачем вам SAS URL :).   -  person Gaurav Mantri    schedule 04.07.2019
comment
@Gaurav Mantri, спасибо за ответ. Это первый случай. Итак, что будет хорошим решением для передачи нового токена клиентской стороне? Любая идея?   -  person Kamil Z    schedule 04.07.2019
comment
К сожалению, нет. Поскольку ваши клиенты напрямую обращаются к BLOB-объекту, вы не узнаете, получили ли они ошибку 403, если они не скажут вам о том же. Когда вас проинформируют, вы можете создать новый токен SAS и раздать его.   -  person Gaurav Mantri    schedule 04.07.2019
comment
Да, я знаю об этом. Я спрашивал о каком-то хорошем решении для клиентской стороны :)   -  person Kamil Z    schedule 04.07.2019


Ответы (1)


Как упоминалось в комментарии, из-за того, что ваши клиенты напрямую обращаются к BLOB-объекту, вы не узнаете, получили ли они ошибку 403, если они не скажут вам о том же.

Если это приемлемо, вы можете взглянуть на Авторизовать доступ к большим двоичным объектам и очередям Azure с помощью Azure Active Directory, когда он настроен, даже если вы меняете ключи учетной записи, клиент также может получить доступ к хранилищу. Но эта функция может применяться как минимум на уровне контейнера, а не на уровне больших двоичных объектов, не уверен, что это приемлемо.

person Joy Wang    schedule 15.07.2019