Новинки Service Bus 2.0. Shared Access Signatures

Совсем недавно в мире Windows Azure произошло знаменательное событие – вышел в свет новый Windows Azure SDK 2.0, который привнес большое количество изменений в процесс разработки под платформу.
Кратко напомню о том, что же нового мы увидели в версии 2.0:

• Веб сайты. Были значительно расширены инструменты разработки для Visual Studio, изменения в основном коснулись процессов разворачивания, управления и мониторинга облачных приложений.
• Облачные сервисы. Добавлена поддержка высокопроизводительных машин A6 и A7. Ускорен процесс публикации сервисов.
• Хранилище. Добавлена возможность работы с Azure Tables прямо из Visual Studio Server Explorer.
• Service Bus. Добавлен целый ряд функциональных возможностей среди которых message pump, shared access signatures, поддержка получения сообщений из очереди без их блокировки и т.д.
• Командлеты Powershell. Расширен набор команд для работы с облачными сервисами и сайтами.

Для более детального ознакомления со списком обновлений рекомендую проследовать на блогпост Скота Гатри, посвященный новой версии SDK 2.0:  http://weblogs.asp.net/scottgu/archive/2013/04/30/announcing-the-release-of-windows-azure-sdk-2-0-for-net.aspx
Сегодняшняя публикация будет посвящена Shared Access Signatures для Service Bus 2.0. Как я уже отметил возможность использовать SAS для Service Bus появилась лишь с выходом версии 2.0.  До этого SAS были доступны только для хранилища. Основное назначение в принципе не изменилось. Shared Access Signatures позволяют предоставлять доступ к Service Bus при помощи предварительного сконфигурированного криптографического ключа. Под доступом подразумевается возможность беспрепятственно работать с такими компонентами Service Bus как очереди, темы и нотификационные хабы (в будущем будет добавлена поддержка relay). Сам по себе криптографический ключ входит в состав правила. Каждое правило определяет уровни доступа, предоставляемые владельцу ключа. При создании правила обязательными параметрами являются первичный ключ, название правила и уровни доступа. Существует ограничение на количество применяемых правил для одной сущности – сейчас это 12. Для того, чтобы получить доступ к защищенному компоненту Service Bus при помощи SAS, клиент обязан предоставить security-токен. Такой токен состоит из URL ресурса, к которому клиент пытается получить доступ, цифровой подписи, вычисляемой при помощи HMAC-SHA256, названия самого правила и времени жизни токена. Токен сохраняется в заголовке Authorization при создании HTTP запроса к Service Bus. В общем виде его структура следующая:

SharedAccessSignature sig=<signature-string>&se=<expiry>&skn=<keyName>&sr=<URL-encoded-resourceURI>

При получении токена инфраструктура Service Bus запускает процесс его валидации и определения разрешена ли указанным правилом запрашиваемая компонентом операция. В случае положительного результата проверки требуемая операция успешно выполняется.
Давайте теперь на примере посмотрим как использовать Shares Access Signatures для аутентификации и получения доступа к Service Bus. Специально для публикации я подготовил простейший солюшен, состоящий из 2-х проектов. Первый проект называется SASRulesManager – это обычное веб-приложение позволяющее создавать правила. Второй проект называется QueueClient – это консольное приложение, при помощи которого мы будем проверять работоспособность созданных правил. Чуть ниже на скриншоте можно увидеть, как выглядит проект в Visual Studio

Как я уже говорил, правило можно применять практически к каждой сущности Service Bus, но в нашем случае мы будем использовать очередь под названием sasdemo. Предварительно ее можно создать, используя расширенный в последней версии VS Server Explorer. Давайте вкратце рассмотрим содержимое основных классов проекта. Итак, начнем прежде всего с ServiceBusManager.cs – здесь собрана вся логика по взаимодействий с Service Bus в общем и с очередью в частности.

namespace SASRulesManager.Models
{
    public class ServiceBusManager
    {
        private const string DEMO_QUEUE_NAME = "sasdemo";
        private NamespaceManager currentNamespaceManager;
        private QueueDescription demoQueue;

        public ServiceBusManager()
        {
            Uri serviceBusUri = ServiceBusEnvironment.CreateServiceUri("https",
WebConfigurationManager.AppSettings["ServiceBusNamespace"], String.Empty);
            TokenProvider tokenProvider = TokenProvider.CreateSharedAccessSignatureTokenProvider(
                WebConfigurationManager.AppSettings["ManagementKeyName"],
                WebConfigurationManager.AppSettings["ManagementKey"]);
            currentNamespaceManager = new NamespaceManager(serviceBusUri, tokenProvider);
            demoQueue = currentNamespaceManager.GetQueue(DEMO_QUEUE_NAME);
        }

        public IEnumerable<SB.AuthorizationRule> GetQueueRules()
        {
            return demoQueue.Authorization.ToList();
        }

        public IEnumerable<SB.AuthorizationRule> AddRule(string keyName, IEnumerable<AccessRights> accessRights)
        {
            var currentRules = GetQueueRules();
            if (currentRules.Count(rule => rule.KeyName.Equals(keyName)) > 0)
            {
                return currentRules;
            }
            var authorizationRule = new SharedAccessAuthorizationRule(keyName,
SharedAccessAuthorizationRule.GenerateRandomKey(), accessRights);
            demoQueue.Authorization.Add(authorizationRule);
            currentNamespaceManager.UpdateQueue(demoQueue);
            return GetQueueRules();
        }
    }
}

Код относительно прост. Как видим у нас есть 2 основных метода и конструктор класса, в котором происходит инициализация очереди. Первый метод GetQueueList возвращает нам список уже существующих правил для выбранной очереди. Второй метод позволяет добавить новое правило к очереди (всего таких правил может быть до 12 штук для одной сущности). Следует отметить, что для получения данных очереди и добавления правил все запросы должны быть аутентифицированы. Достигается это при помощи все тех же Shared Access Signatures, как видим название правила и криптографический ключ берутся из Web.config при создании экземпляра классаTokenProvider. По умолчанию при создании очереди создается правило с полным набором прав, посмотреть которое можно в диалоге ConnectionInformation на портале разработчика.

Увеличить
Следующий важный элемент – это MVC контроллер SASController. Исходный код контроллера представлен ниже:

namespace SASRulesManager.Controllers
{
    public class SASController : Controller
    {
        //
        // GET: /SAS/

        public ActionResult Index()
        {
            var serviceBusManager = new ServiceBusManager();
            return View(serviceBusManager.GetQueueRules());
        }

        [HttpPost]
        public ActionResult Index(string ruleKeyName, string ruleAccessRights)
        {
            var serviceBusManager = new ServiceBusManager();
            var accessRights = ruleAccessRights.Split(new string[] { "|" }, StringSplitOptions.RemoveEmptyEntries).
                ToList().
                Select(entry =< (AccessRights)Enum.Parse(typeof(AccessRights), entry));
            serviceBusManager.AddRule(ruleKeyName, accessRights);
            return View("Index", serviceBusManager.GetQueueRules());
        }
    }
}

Здесь мы видим 2 экшена, первый для отображения странички с созданными правилам и контрола для создания новых. Вот как она выглядит:

Увеличить

На скриншоте можно заметить 3 правила, каждое из которых содержит различный набор прав. Всего существует 3 вида прав:

• Listen. На чтение очереди
• Send. На отправку сообщений в очередь
• Manage. На управление очередью.

Естественно их можно комбинировать в любой последовательности.
Второй экшен контроллера предназначен для приема POST запросов от страницы, разбора параметров и добавления созданного правила к тестовой очереди.
Давайте теперь перейдем к проекту QueueClient – он очень простой. Основной код сосредоточен в Program.cs.

namespace QueueClient
{
    class Program
    {
        static void Main(string[] args)
        {
            Uri serviceBusUri = ServiceBusEnvironment.CreateServiceUri("sb", "feschenko", String.Empty);
            TokenProvider tokenProvider = TokenProvider.CreateSharedAccessSignatureTokenProvider(
                "SimpleSendRule", "J9SCe/giY2aO6vaY1mcB2oCtXeRANHiUmhlzLAibDtg=");
            MessagingFactory factory = MessagingFactory.Create(serviceBusUri, tokenProvider);
            var queueClient = factory.CreateQueueClient("sasdemo");
            var message = new BrokeredMessage("Test Rule Message");
            message.MessageId = Guid.NewGuid().ToString();
            queueClient.Send(message);
        }
    }
}

В коде мы создаем экземпляр очереди и пытаемся отправить тестовое сообщение. В случае если мы используем правило, позволяющее нам это сделать (то есть содержащее право Send) – код выполняется успешно. Иначе, обязательно вылетит исключение, извещающее нас о том, что мы не авторизованы для подобных действий.

Увеличить

На этом всё, как видим Shared Access Signatures -  это мощное средство, которые можно использовать для получения доступа к элементам Service Bus в удобном и быстром виде с поддержкой различных уровней доступа.
Ссылка на скачивание разработанного проекта:  https://dl.dropboxusercontent.com/u/18522369/Blog/ServiceBusSAS.zip