“Necessity is the mother of invention”

The Windows Azure Platform currently offers the ability to have an administrator and 10 co-administrators associated with every account (Thanks to Steve Marx’s help to figure out that number), which introduces a limitation when 11 or more team members want to share the same account. In this post, I’m going to illustrate the different ways to avoid this limitation, and I’m pretty confident that at some point in the near future the platform will support a much more sophisticated user management interface.

Some rules of thumb: Treat the account as your online banking credentials. Whoever is paying the bill should frequently keep an eye on the consumption for any suspicious activity. Periodically renew the password or refresh the management certificates, and remember that the more people that share a secret, the less secret it is

Even though we all know the rules, sometimes (in some cases, many times) we don’t follow them. So here are the different ways I’ve used to share the same account.

Share Co-Admin Credentials

One of the light overhead ways to share the account is to create a single LiveId account and give the credentials to every team member. This way everyone can login to the Windows Azure Portal as a co-administrator. To add an additional layer of safety, you can periodically change the password, this way you can avoid cases where someone left the group and still has the password or probably someone engraved the password in their favorite pub’s bathroom on a drunk night (yes ladies, you would be surprised with what’s in there )

Share A Jump Box

A jump box could be a dedicated machine or virtual machine where you save the co-admin credentials in the browser, then anyone who needs to deploy a service will have to login to the jump box with some operating system credentials. This technique is painful (imagine the process: package your service –> remote login into the machine –> copy the package and config file –> deploy through the portal) but more secure because the jump box could live under the corporate network and the credentials of the Windows Azure account are not shared with the users. Ohh by the way, only one user can be logged in to the box at a time, so depends on your team size, you might need more jump boxes.

I followed this process for like a couple of weeks until the team wide bug bash day arrived where I had to apply few fixes and deploy multiple times, and trust me I wasn’t in the best mood afterwards, the extra step of copying the files and deploying through the portal felt like ages

Share A Certificate And Subscription ID

(My favorite and most practical way)

At the moment, the Windows Azure Portal allows you to deploy a maximum of 10 certificates to your account, which will allow you to use the service management APIs to manage your account. You can create a single password protected certificate and share it with everyone on your team or you can have multiple certificates for different employees status (for instance, you can have a certificate for your full time employees, another one for contingent staff, another temporary certificate for developers who are not on the services side of the house but decided to experiment with cloud based services part of their out of the box projects. Once a user has the certificate installed on their machines and the associated Azure account subscription ID, they’ll be able to use the sweet visual studio publish button to package and deploy their service, or any of their favorite Azure Service Management Tools

Finalement (finally in French)

Sharing a certificate and subscription ID is my favorite approach because I mostly use the client side tools to deploy and manage my applications.

Please share any other ways your team applied and what you like and don’t like about them.