1
votes

I am currently trying to understand the combination of Azure ACS with Claims-based Auth and the option of using a custom STS and I am only slowly getting through the (unfortunately few) info sources. Before I spend more hours on this I would like to confirm if my plan is even possible. I have multiple azure roles (web+worker) that are being accessed over the internet by both employees and customers. Additionally, employees access these roles and desktop apps from inside our local network.

User data comes from two sources. Our azure app has user data about customers and employees, our (local) AD only from employees.

To make the login experience as efficient (and ergonomic) as possible, when accessed via our local network, employees should be automatically authenticated (Windows Integrated Auth?) on both the desktop app (automatically because of Windows User Profile Context) and on the azure apps (hopefully w/o login page). Customers, on the other hand, should enter their user credentials when accessing the azure app, but should not have to decide between different "Credential-sources", they should just get the username+password form. In other words

  • Employee visits Azure app from local network -> Auto-login with Integrated Auth / AD data
  • Employee visits Azure app from internet -> Username+Password form
  • Customer visits Azure app from internet -> Username+Password form

While writing this question, two more came to mind:

1) Is it even possible to auto-login based on source/cookie/wizardry or would that require a manual user choice for selecting the "Credential-Source"?

2) If Azure ACS "knows" that AD account with Username X is the same as Azure App User Y, does it matter with which one logins? Can the app access the same claim-data on either login route?

2

2 Answers

1
votes

Are you sure you need a custom STS? It sounds like to start you just want to enable your AD users to sign in to your azure applications using their windows credentials if they are on the domain (no password prompt). ADFS 2.0 and WIF will facilitate this. In addition, if you set up an ADFS proxy server so that when those same users browse to your app from outside of the domain they will get prompted for their domain credentials.

Now your AD users are set up, but if you want your applications to be accessible to users outside of your domain, you can federate ADFS with another organization's ADFS server, or use ACS to enable login using consumer identity providers such as Google, Yahoo, and LiveID, which are provided as built in options. If you did introduce ACS like this, you would configure your corporate ADFS server as an identity provider on your ACS instance alongside google, yahoo and what not, so that when your users browse to your site they will be prompted to select which identity provider they wish to sign in with.

Here's a fantastic whitepaper that demonstrates using ADFS to authenticate to cloud applications:

http://www.microsoft.com/download/en/details.aspx?id=13789

More detailed info about deploying ADFS (such as deploying the ADFS proxy) can be found in technet.

And for ACS, there are guides and samples on how to integrate it into azure applications, and how to add ADFS identity providers: http://msdn.com/acs

0
votes

One thing that you could do is look at the user credentials when a page is requested in order to get the authentication info.

If you look at...

HttpContext.Current.User.Identity

You can get info about the user's identity. If they are on the domain you will see that they have a domain name and you could programmatically choose to direct them to a login page.

Let me also say that I've never tried to do this so I don't know if there's a built in way to do this by simply configuring something in web.config.