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!

Wiry

Wow open ended question, I have used ACS in Production and love it, one limitation, not on ACS but on Windows Live is that you can not get the Claim Type for the person's email address 'AZURE ACS - Windows Live ID - How do I get the email and name of the authenticated user?': #7872460 You can work around this but I felt it was annoying. Interested to see what other people think!! – Lethe

@user728584: Thanks for the link. The fact that I still have to manage my own user registrations is brought up in that question as well. Yeah, I've been digging into ACS documentation, Vittorio Bertocci videos, etc. for a while now :), and asking it the other way around is hopefully going to make things clearer. – Wiry

Well your on the right track with Vittorio (admiral identity). ADFSV2 is excellent too, my clients use it along with forms based auth (existing functionality) to offer the general public a social media login e.g. Facebook abstracting all the security nasties to ACS, works a treat! – Lethe

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.

Votive

Thanks, that's the kind of thing I'm looking to understand. (I was considering doing exactly that, actually. I have a large number of client devices that need to authenticate with individual X.509 certificates. I've struggled with how to conceptually tie that into ACS. Topic for another question, though.) – Wiry

Answer 2

Even though you can use Windows Live as identity provider in ACS, there are some cases where you would not want to use it. The user ID you receive depends on the ACS namespace. This means that if your application uses multiple ACS namepaces (lets say one for europe and one for USA) this might cause some issues.

Imagine the scenario where your user logs in through your USA namespace. Your application will receive the ID (hash) for that user and you'll maybe create a profile for that user in your application. A week later your user travels to europe and might log in through your europe namespace. Even though this is the same user, you'll get an other ID (hash) for that user, making it seem this is a new user, even though it's not. This is because the ID (hash) depends on the ACS namespace.

Quoting an MSFT employee:

The user ID that you receive from ACS for Windows Live ID will be specific to that user at your service namespace. If you use a different service namespace, you'll get a different value for the same user. So to answer your questions: * Labs ACS and Prod ACS [Different IDs]

• Different relying parties in different subscriptions (in prod) [Different IDs]

• Different RPs in the same subscription [Same ID if the service namespace is the same, different for 2 namespaces in the same subscription]

• If I delete and rebuild the RP to the same realm, same account [Same ID]

Update:

To reply on one of the comments, it's true that you won't get the email address from the Windows Live identity provider. But you should assume that you can't control the information you'll get from public identity providers. A good practice would be to simply depend on the identifier of the user and to create a profile for the user (you'll manage the profile in your application). When you get some information from the identity provider you can already update the profile, but if this info isn't available you should simply ask the user to update his/her profile. Be sure to look at the BlobShare example for more info.

Galengalena

+1 for a thorough answer. But what you're addressing is a technical (well, by-design) limitation of ACS in a particular scenario. I'm more interested in what scenarios are out there where ACS would not be a good fit. – Wiry