In this blog series I explore some of the shortcomings of the Microsoft Azure platform (as of this date, April 2014) and discuss ways it could be improved. This isn’t a rant against the platform: I’ve been using and promoting the platform for more than four (4) years now and I’m very passionate about it. Here I am pointing at problems and suggesting solutions. Feel free to jump in the discussion in the comments section!
The past blog entries are:
What is the security model of Microsoft Azure?
This question is at the heart of the weakness I would like to discuss in this article: there are no unique security model in Azure. There are a plethora of models, depending on which Services you are consuming. Let’s look at some examples:
- Azure Storage: you can either use an access key (there are two: primary or secondary) in the Authorization cookie of HTTP requests, which gives you all privileges within an entire storage account or you can use Shared Access Signature (SAS) that you place in the query strings of your HTTP requests, which gives you limit access (see valet key). There are actually two flavours of SAS, an ad hoc form and a more permanent one.
- SQL Azure: user name / password of an SQL Account. This is the same mechanism used with on-premise SQL Server that has been discouraged by Microsoft to used in opposition to the Windows Integrated mechanism, which isn’t supported by SQL Azure.
- Service Bus: access token provided by Access Control Service (ACS) or a SAS (independent of the Azure Storage SAS). Both mechanisms can give limited access to resources (see my past blog on how to secure Service Bus access).
- Azure Active Directory Graph API: JWT access token provided by Azure Active Directory using OAuth-2.
Those are just a few and they are the access to the service itself. When you want to manage those services (e.g. creating an SQL Azure Database), you may have a different security model.
If you use Microsoft Azure lightly, i.e. one or two services, it might not appear as a problem. Once you start using Azure a bit more as a development platform, then this lack of uniformity will hit you:
- You have a lot of protocols to understand and implement.
- You need to work around different limitations, e.g. I can be very granular on access on the Service Bus but with SAS Policies in Azure Storage, the SAS is good for an entire container.
- You have a lot of secrets to store, since many Services do not share secrets (see my blob on secrets for more details).
- You have a lot of credentials to manage, e.g. you need to implement retention policies and renew different secrets in different services which all have different management interfaces. This increases the chances of error or more typically, of not automating such policies.
How could we fix that?
I would propose a dual security model for each Service.
The primary Security Model would be Claims based and not even limited to Microsoft Azure Active Directory but open to any Identity provider. For ease of use, your Azure Subscription could be configured with a set of trusted Identity Provider (i.e. URI & signing keys, token type). When you want to configure an access you could then have a standard dialog where you pick the Identity Provider and compose a Claims rule (e.g. I want the claim type & claim value or those types & value, or either this combination or that one, etc. .).
This would enable your solution to have Service Identities managed wherever you want (although Azure Active Directory would be easier since it is part of the platform) and the same Identity could be used to access SQL Azure, Service Bus, Media Services, etc. . Quite a bit like we do on-premise with Service Accounts.
The access token provided by the Identity provider would need to be passed in the Authorization cookie at each HTTP Request or differently for different protocol (e.g. TCP TDS for SQL, proprietary TCP for Service Bus, etc.).
The secondary Security Model could be unique to each Service but would typically address the shortcomings of the primary one. The primary model I define here requires access to an Identity Provider (this one must be up), configuration of an account in that Provider, etc. . A simpler Security Model, e.g. SAS, would be quite good for faster ramp-up with a Service (although it has the weakness of multiplying the number of secrets).
With this Primary / Secondary Security Model we would have a robust security model (Primary) and one for quicker use (Secondary). When using the primary security model, it is quite possible to have only one secret to store for an application: the user name & password of the Service Identity associated with the application. This would allow for central management of the secret and much less complex logic to store and use the secrets.
Hope this was useful!