Currently, only the primary administrator for a subscription can access the ACS portion of the portal for namespaces. Co-administrators receive an error message when trying to do so. Co-administrators should have the same ability as the primary administrator.

In my case, the owner of the company I work for is the administrator for the subscription. However, among other things I am in charge of all configuration of Azure. To facilitate this, he made me a co-administrator. Currently I cannot configure ACS when logged in under my own account.

Today SAML Tokens which are signed using a certificate issued by a local CA cannot be validated and are therefore rejected by ACS. This is because ACS only trusts Root CAs which are on the out-of-the-box windows trusted CA List. It would be very useful for ACS Customers to decide for themselves which Root-CA they trust or not.

Error reporting via a limited number of error codes is essentially worthless for debugging purposes -- http://msdn.microsoft.com/en-us/library/windowsazure/gg185949.aspx.

When trying to set up a federation relationship with other organizations who might support WSFed (but aren't using WIF) a lot more detail is needed to troubleshoot issues... You shouldn't have to submit a support ticket every time you need to find the details behind a Trace Id. Thanks!

When selling software applications we are often at the mercy of a customer in regards to what platform they want to run on. Some customers will want internally hosted Win Server solutions, others will want Azure and others will prefer other Cloud solutions. Having to maintain different code bases for different platforms adds a maintenance overhead and level of duplication we could do without. It would be nice if the AppFabric libraries were unified so that the same code could be deployed to Windows Server or Azure

Currently the app fabric cache only allows objects of upto 8 MB to be stored. This is a big limitaion in the following scenarios..
1. When session state is using appp fabric cache.
2. In case of applications which show data on web pages after retrival from table storage. This is because the data is held inside a dataset which has to be stored in the session

This binding should support JsonP just like the WebHttpBinding supports it.

The nameidentifier claim containing a made up ID unique to my application is not sufficient for authenticating a user. With no way to get additional user identifiable information, a user could authenticate with Live and then fill out a local profile on my application for whomever they wanted. They could claim to be Bill Gates, I would have no way of verifying that based on the nameidentifier claim coming from LiveID.

The ACS authentication system does not implement widely used anti-hacker HTTP headers.

Please see the following links for a list of missing HTTP headers:

http://security.stackexchange.com/q/8480/396
and

http://social.msdn.microsoft.com/Forums/en-US/windowsazuresecurity/thread/eab4b53e-438b-4b20-8933-ae88e2f3610f?prof=required

It would be nice if code did not even require recompiling to be hosted on premise or in cloud

Without an ability to traverse collections of things the Azure cache is not very useful. Here's hoping they add notifications, regions, and tags.

May be useful for developers to have an AppFabric Cache emulator, for instance.

$45/mo for 128MB cache is cost prohibitive.

Ability to autoscale web and worker roles based on CPU load, Queue depth, etc.

Idea created Sep 8, 2010 by Lars W. Andersen

It is a problem operating the Azure account, when only one admin have access to it. In case of emergencies, vacation, etc. it is needed to share access to one account.

[moved from Windows Azure Feature Voting]

Sorry to be a bit snarky here. I initially was extremely excited that Microsoft was adopting uservoice, this is a great step forward, but without showing activity in accepting ideas people may turn elsewhere. In the same time competitors such as Amazon have added considerable new features, I'm hopeful that Azure will be a great player in the market.. seeing some action here would certainly help.

I think it's great that we finally have support for Flash/Silverlight on the ACS. However, I think the support is poorly implemented.

The current policy is expressed as

<cross-domain-policy>
<allow-access-from domain="*" secure="true" />
<allow-access-from domain="*" secure="false" />
<allow-http-request-headers-from domain="*" headers="*" secure="true" />
<allow-http-request-headers-from domain="*" headers="*" secure="false" />
</cross-domain-policy>

I'd prefer to be able to add the domains that can access the service from Flash/SL via the administrative UI since my use cases for ACS are for single applications, not for the world at large.