Контроль доступа к контенту на уровне доступа с помощью Java

Question

Я пытаюсь создать приложение Java, работающее на локальном сервере, которое управляет разрешениями доступа к блокам, которые хранятся в Windows Azure. Ресурсы облачного хранилища используются несколькими мобильными приложениями (также написанными на Java), которым необходим доступ на чтение, а иногда и временный доступ на запись, к одному контейнеру blob, размещенному в облаке. Я использую Windows Azure Plugin for Eclipse with Java by Microsoft Open Technologies.

Мой вопрос: Как (или если) уровень контейнера stored access policies в Azure можно сделать для возврата к ранее сохраненной политике (READ) по истечении срока действия, а не к «без доступа». "

Статья MSDN: Creating a Shared Access Signature in Java обеспечивает хороший старт, но он пока не говорит о том, как использовать хранимые политики на уровне контейнера для управления политиками доступа общего доступа с Java. Я изучаю Java и SAS, и потому, что мне не удалось найти примеры кода Java, похожие на Access Control for Azure Blobs, я включил короткую часть кода Java ниже, чтобы продемонстрировать мой вопрос.

Серверное приложение извлекает строку подключения частного хранилища, используемую для подключения к хранилищу Azure. Получает учетную запись облачного хранилища и создает клиент облачного blob. Получает ссылку на контейнер и создает контейнер, если он еще не существует. (Обратите внимание, что имя контейнера должно быть в нижнем регистре.) Затем он загружает текущие разрешения для контейнера. (Для контейнера может быть сохранено до пяти сохраненных политик хранилища на уровне контейнера).

Например, есть две политики хранимого доступа с именем «baxter» и «heath», которые контролируют разрешения на уровне контейнера, и что обе политики были установлены в READ (только), когда сохраненные политики доступа контейнера были ранее сохранены. Эти первоначальные политики с разрешениями READ истекают через несколько месяцев. Мобильные приложения, назначенные либо «вереск» или политика «Бакстер», то начать с чтением-доступом к сгусткам, хранящимся в sascontainer6 через Ури строки, подобные:

http://grassy.blob.core.windows.net/sascontainer6/image4.jpg?sr=c&sv=2012-02-12&sig=5G7EOgiYYNEGmw2Y0T4IUgt%2FzTnmYpaxWfB5nEira08%3D&si=baxter 

http://grassy.blob.core.windows.net/sascontainer6/image4.jpg?sr=c&sv=2012-02- 12&sig=llUoAg2PvFUfhO28ncrlheh2RRJdb7smQEX6nO8xoCk%3D&si=heath 

В случае необходимости, сервер приложения могут поднять подмножество мобильных приложений для разрешений READ и WRITE без необходимости выпуска новой строки. Он может сделать это, изменив политику «baxter», сохраненную в контейнере. «Степень детализации» элемента управления находится на политическом уровне, и обновление политики позволяет всем мобильным приложениям, назначенным политике «baxter» писать (или перезаписывать) капли в контейнере. Мобильные приложения, назначенные политике «heath», продолжаются для получения разрешения READ (только). Аналогичным образом серверное приложение может отменить весь доступ к контейнеру для приложений, назначенных для определенной политики.

Перед изменением политики серверное приложение обеспечивает открытый доступ к контейнеру был отключен, он указывает текущее время как время начала и время истечения для доступа, которое составляет один час после начала. Он устанавливает разрешения READ и WRITE для новой политики. Наконец, существующая политика «baxter» переписывается новой политикой.

Метод generateSharedAccessSignature может получить подпись общего доступа (SAS) для политик «baxter» и «heath». Изменение разрешений, сохраненных в политике, не должно изменять SAS, а приложения, использующие вышеуказанные строки uri, должны работать до указанного времени истечения.

Однако, по достижении срока годности, строка «baxter» потеряет все разрешения для контейнера, как READ, так и WRITE. Но это не то, что я хочу. Мне нужны разрешения для мобильных приложений, назначенных для политики «baxter», чтобы вернуться к READ (только). Поскольку строка SAS с доступом WRITE позволяет кому-либо писать ресурс, наилучшей практикой является сохранение периода между временем начала и время истечения как можно короче, не более часа.Установка разрешений на READ для более длительных периодов приемлема для моего конкретного приложения.

Мой вопрос: как (или если) политики общего доступа на уровне контейнера в Azure могут использоваться, чтобы разрешить токен (т. Е. Строку «baxter», показанную выше) вернуться к альтернативной политике (например, READ) чем «без доступа».

public static void main(String[] args) throws InvalidKeyException, URISyntaxException, StorageException 
    {   
    Account creds = new Account();    
    final String storageConnectionString = creds.getstorageconnectionstring(); 
    CloudStorageAccount storageAccount = CloudStorageAccount.parse(storageConnectionString); 
    CloudBlobClient blobClient = storageAccount.createCloudBlobClient(); 
    CloudBlobContainer container = blobClient.getContainerReference("sascontainer6"); 
    container.createIfNotExist(); 
    BlobContainerPermissions containerPermissions = container.downloadPermissions(); 
    containerPermissions.setPublicAccess(BlobContainerPublicAccessType.OFF); 
    SharedAccessBlobPolicy policy = new SharedAccessBlobPolicy(); 
    GregorianCalendar calendar = new GregorianCalendar(TimeZone.getTimeZone("UTC")); 
    calendar.setTime(new Date()); 
    policy.setSharedAccessStartTime(calendar.getTime()); 
    calendar.add(Calendar.HOUR, 1); 
    policy.setSharedAccessExpiryTime(calendar.getTime()); 
    policy.setPermissions(EnumSet.of(SharedAccessBlobPermissions.READ, SharedAccessBlobPermissions.WRITE)); 
    containerPermissions.getSharedAccessPolicies().put("baxter", policy);    
    container.uploadPermissions(containerPermissions); 
    String sas = container.generateSharedAccessSignature(new SharedAccessBlobPolicy(),"baxter");   
    String sasex = container.generateSharedAccessSignature(new SharedAccessBlobPolicy(),"heath");   
    } 

Answer 1

Вы демонстрируете хорошее понимание политики доступа к контейнеру вместе с SAS. Все объяснил, приводит к очень конкретный вопрос:

Мой вопрос: как (или если) контейнер уровня разделяет политику доступа в Azure можно использовать, чтобы маркер (т.е. «Бакстер» строка показано выше), чтобы вернуться к альтернативной политике (т.е. РИД), а не «нет доступа».

Какой»ответ, к сожалению, является NO. Вы не можете определить fallback для того, что происходит, когда истекает срок действия политики на уровне контейнера. Как только он истечет, все кончено. Ни один SAS, связанный с ним, не может выполнять никаких действий над связанными ресурсами. Вы должны, со своего кода на стороне сервера, явно переписать его с новыми разрешениями и новой датой истечения срока действия.

Но я хочу немного оспорить вашу концептуальную архитектуру. У вас есть заявление:

В случае необходимости, сервер приложений может поднять подмножество мобильных приложений к как на чтение и запись без выпуска новой строки.

Даже если ваш server делает так, как мобильные клиенты понимают, что теперь они могут также write, а не только read из этого облачного хранилища? Я действительно сомневаюсь, что ваши мобильные клиенты всегда стараются писать молча, если они не могут.

Я предполагаю, что существует некоторая связь server-to-mobile-client, прежде чем мобильный клиент осознает, что он может писать в облачное хранилище. Если такого общения нет, то что-то ужасно нарушается ИМХО.

Однако, если такое сообщение существует, ничто не остановит вас от предоставления новой более короткой жизни SAS с разрешениями RW (чтение и запись). Этот новый более короткий срок службы SAS может быть даже stand alone SAS, что означает, что он не связан с какой-либо хранимой политикой доступа и не выпускается специально для записи в капли.

Мое другое предположение, что вы хотите избежать отправки SAS по проводу, чтобы избежать атак типа man-in-the-middle. И, скорее, хотите предварительно настроить SAS в приложении. Если это так, я могу предложить иметь отдельные политики доступа для чтения и записи. Вы можете безопасно получить политику доступа expired для написания и сделать ее действительной только в случае необходимости. На вашем устройстве теперь будет 4 SAS URI вместо 2, но он (устройство) точно знает, какая политика доступна только для чтения, и с помощью которой можно попытаться выполнить запись. Обратите внимание, что даже истек, политика доступа на запись по-прежнему связана с контейнером, она не удаляется. Поэтому вам просто нужно обновить его в следующий раз, когда вы хотите, чтобы он был активным.