External web service and Active Directory - which authentication type?

[sqlman]

Windows 2008 Server, IIS 7
ASP.NET 1.1 web service

I have a ASP.NET 1.1 web service on the external machine for which I
need to implement proper authentication mechanism. I have an Active
Directory domain also in DMZ (specifically for external users), and I
would like to use the existing user base and roles in it.

The easiest approach seems to enable Windows authentication on the
virtual directory of the web service, and let IIS handle
authentication. But from what I have seen, Microsoft strongly
discourages use of Windows authentication on the Internet.

What are my alternatives and how would I implement them?

 

[DaveMo]

Windows 2008 Server, IIS 7
ASP.NET 1.1 web service

I have a ASP.NET 1.1 web service on the external machine for which I
need to implement proper authentication mechanism.  I have an Active
Directory domain also in DMZ (specifically for external users), and I
would like to use the existing user base and roles in it.

The easiest approach seems to enable Windows authentication on the
virtual directory of the web service, and let IIS handle
authentication.  But from what I have seen, Microsoft strongly
discourages use of Windows authentication on the Internet.

What are my alternatives and how would I implement them?

The only other decent option is to use forms-based authentication. But
really it comes down to a matter of preference for the user
interaction during authentication. With Windows Integrated AuthN the
user will see the dialog box provided by Windows. It's not very user
friendly and lacks context. Also if the user forgets their password or
needs to change it, then the user is stuck or at best confused.

For this reason, most people go with forms-based auth for external
authN scenarios. Good info here: http://msdn.microsoft.com/en-us/library/aa480476.aspx

Security issues with Windows integrated auth comes mainly when users
choose very bad passwords. This problem can be mitigated by enforcing
strong passwords or protect the initial page in your site with HTTPS.


HTH,
Dave

 

[sqlman]

The only other decent option is to use forms-based authentication. But
really it comes down to a matter of preference for the user
interaction during authentication. With Windows Integrated AuthN the
user will see the dialog box provided by Windows. It's not very user
friendly and lacks context. Also if the user forgets their password or
needs to change it, then the user is stuck or at best confused.

For this reason, most people go with forms-based auth for external
authN scenarios. Good info here: http://msdn.microsoft.com/en-us/library/aa480476.aspx

Security issues with Windows integrated auth comes mainly when users
choose very bad passwords. This problem can be mitigated by enforcing
strong passwords or protect the initial page in your site with HTTPS.


HTH,
Dave

Dave,

I am aware of all that, but I am talking about a web service, not an
interactive web app. So, Forms seems to be out of question.

Thanks!

 

[DaveMo]

Dave,

I am aware of all that, but I am talking about a web service, not an
interactive web app.  So, Forms seems to be out of question.

Thanks!- Hide quoted text -

- Show quoted text -

Ahh, sorry. Missed the web service piece in my first read. For
automated processes the choice comes down to password-based challenge
response protocols which include NTLM and Digest. The two have
similiar security characteristics, so I'd likely suggest NTLM.
Otherwise you can choose client certificate authentication using X.509
certificates. These are all out of the box mechanisms. Note that
client cert authN requires SSL, but if you use SSL then NTLM auth is
perfectly secure as well. It really just comes down to what your
external customers are going to have to do to manage their credentials
of whichever type you choose to accept. Is it easier for them to
manage passwords or certificates?

For completeness I should probably mention federation-based
approaches, but knowing nothing about the external users I couldn't
say whether that approach would be worth looking in to.
HTH,
Dave

 

[sqlman]

Ahh, sorry. Missed the web service piece in my first read. For
automated processes the choice comes down to password-based challenge
response protocols which include NTLM and Digest. The two have
similiar security characteristics, so I'd likely suggest NTLM.
Otherwise you can choose client certificate authentication using X.509
certificates. These are all out of the box mechanisms. Note that
client cert authN requires SSL, but if you use SSL then NTLM auth is
perfectly secure as well. It really just comes down to what your
external customers are going to have to do to manage their credentials
of whichever type you choose to accept. Is it easier for them to
manage passwords or certificates?

For completeness I should probably mention federation-based
approaches, but knowing nothing about the external users I couldn't
say whether that approach would be worth looking in to.
HTH,
Dave

Dave,

The whole point of this is to use the Active Directory to manage
users, and let them get authenticated against it. From what I gather,
client certificates lead to something else.

I am also still confused: what is wrong with using Windows
authentication (with SSL or not), and how is it inferior to NTLM or
Digest?

Thanks!

 

[DaveMo]

Dave,

The whole point of this is to use the Active Directory to manage
users, and let them get authenticated against it. From what I gather,
client certificates lead to something else.

I am also still confused: what is wrong with using Windows
authentication (with SSL or not), and how is it inferior to NTLM or
Digest?

Thanks!- Hide quoted text -

- Show quoted text -

Windows authentication includes both Kerberos and NTLM authentication.
Kerb won't work in your scenario, so Windows authentication = NTLM.

Client certificates can be used to authenticate users in Active
Directory. Everything I've mentioned so far is a way to authenticate
AD users, so it's up to you to pick the option you like the best.

Dave