1

We have a .NET WebAPI that we want to allow domain users access to. We want to support building JavaScript single page applications to get and present data from the WebAPI. Those JavaScript applications should be able to run in a browser on a domain joined PC, on a tablet outside the network, on a phone, in browsers that are not IE, etc. Native clients are a potential future target, but not entirely required.

Assume we have the authorization side figured out such that the key issue here is authenticating the user against the on-premise Active Directory so we can see their identity (domain\user) in our WebAPI middleware.

If we just enable Integrated Windows Authentication in the WebAPI (and IIS), that seems fine for intranet scenarios. I see a lot of vague warnings around using it for internet/outside the domain scenarios.

Specifically I see concerns over using NTLM, that it is not secure enough, and also that NTLM can be blocked via certain web proxies. And in general a sense that this is an "old fashioned" way to do it. But not much in the way of details.

Can anyone provide me more specifics on those concerns or bring up other security concerns that would make this approach a bad idea?

Peter M
  • 472
  • 5
  • 16
  • Is there any chance to sync your AD account with Azure AD? If this is available option then implementing this will be easy. Let me know if this is an option so I provide you with my suggestion. – Taiseer Joudeh Dec 15 '14 at 11:56
  • While moving to Azure is on our roadmap, we have to support fully on-prem deployments for a while. Some of which are secured in such a way that we are not allowed to sync AD with Azure AD. Otherwise I'd use ADAL with the new preview JS library. Good suggestion though – Peter M Dec 15 '14 at 15:58

1 Answers1

2

Kerberos authentication will work for domain joined devices inside your intranet. But most phones and tablets cannot be domain joined. Also, to allow authentication against Active Directory, you'd have to expose your AD to the internet, which is something your administrator will surely be opposed to.

You could use ADFS with a proxy exposed to the internet and use token based authentication. That would allow anyone with domain credentials to authenticate. ADFS supports various protocols to get a security token (SAML, WS-Federation, WS-Trust and 3.0 also supports OAuth 2.0 code flow).

ADFS 3.0 also supports Bring Your Own Device (BYOD), which allows you to register devices to which it will issue tokens.

Alternatively, you could sync your Active Directory to Azure Active Directory (AAD) and use that as authentication provider.

MvdD
  • 22,082
  • 8
  • 65
  • 93
  • While Kerberos will not work for those tablets and phones, NTLM will; the user will get prompted to enter their credentials by the browser. For ADFS, I believe that the OAuth 2.0 implicit flow is NOT supported. – Peter M Dec 15 '14 at 01:49
  • @PeterM, you're correct. I fixed the flow in the answer. While NTLM may work in this case, I don't think it's recommended to use anymore. http://blogs.technet.com/b/authentication/archive/2006/04/07/ntlm-s-time-has-passed.aspx – MvdD Dec 15 '14 at 04:17
  • that is mostly where I've ended up in my research too. That NTLM may work but nobody likes it. The link you provided pointed out some potential crypto issues, which I can look into. It also pointed to server-to-server communication which I excluded from this question to keep the focus narrow – Peter M Dec 15 '14 at 16:03
  • We ended up using a more modern, token based approach to secure our API and limit how much we had to rely on NTLM or Kerberos. Marking this as the answer since it raises some good points and discussion – Peter M Jan 07 '15 at 15:26