On Jun 3, 9:34*am, sqlman <n...@abc.xyz> wrote:
> On Mon, 1 Jun 2009 12:36:47 -0700 (PDT), DaveMo
>
>
>
>
>
> <david.mow...@gmail.com> wrote:
> >On May 29, 10:41*am, sqlman <n...@abc.xyz> wrote:
> >> 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
>
> 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
Similar Threads
