When not to use ACS?

Question

I've been researching the Azure Access Control Service (ACS), and it looks like it's especially good at handling authentication from heterogeneous (configurable) identity providers. Then there are a number of additional scenarios that it appears to support (see for example ACS How-To's).

The question I have is the opposite: it would really help me to understand, in order to use it properly, what ACS is not good for. What are the limitations of ACS, and/or what are some scenarios where ACS would be inappropriate?

(Assume, for the sake of argument, that I plan to create a - profitable :) - public web API and corresponding web site front-end, hosted in Azure - i.e., that I do care about user identity. If you like, you can further assume that my system will be built using .NET.)

Thanks!

Answer 1

You shouldn't use ACS as an identity provider.

Occasionally I see some confusion as to what role ACS serves. ACS at is core is a federation provider, but there is a valid scenario in which you want your backend service (a trusted subsystem) authenticating directly to ACS using a shared secret or a certificate. This can be done using Service Identities. However, more than once I've seen an ACS scenarios proposed where multiple accounts are to be provisioned, and this was going to be achieved by creating a service identity for each user.

That's really not how ACS is designed. If you suddently have thousands of users, making ACS your authoritative source user directory won't scale. ACS offers a nice rules engine that was designed for normalizing incoming claim types from various identity providers, or for simple authorization policy such as generating role claims.

But ACS' capabilities here should not be confused with fully powered directory, authentication and authorization solutions such as AD and ADFS. In short, ACS is not a could version of AD/ADFS.