Mixed Mode Authentication in .net 2.0

[Graham Lloyd]

Hi there

Our web site requires Integrated Security switched on and anonomous disabled
so each users credentials are valid when accessing a database on the server.
This is all working fine but now I want to allow remote users, eg at an
airport or internet cafe, remote access.

Currently they are prompted via IIS for there credentials but we want to
direct them to our own login page then authenticate them using Forms
security with Active Directory.

I've read ths paper on MSDN
(http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnaspp/html/mixedsecurity.asp)
and also a few others but our remote users are always prompted by the IIS
login box.

Can anyone point me in the right direction?

Cheers

 

[Joe Kaplan \(MVP - ADSI\)]

If I were doing this, I would implement it with ADFS, as it gives you nice
integration with both integrated auth and forms authentication, while still
allowing the web application to make use of Windows security tokens for
security purposes. Their solution is really clean and does exactly what you
want.

However, ADFS is a big thing to set up if you aren't trying to implement
identity federation or SSO otherwise.

One thing you might do is use split DNS or something like that so that one
version of your app is available on the public internet and the integrated
auth version is available internally. There isn't a good way to make the
integrated prompts go away for some users if you still want integrated auth.

Another option is to enable Basic auth with SSL and make everyone supply
credentials. Some users won't like it, but it is very simple and will just
work.

Joe K.

 

[Graham Lloyd]

Thanks for the info. I've not come across ADFS before. Can you point out any
good links.

I will do some research into this.

Also, do you know if MS is intending to update its Basic Authentication
method to encrypt the users credentials in a more secure way for future
reelases of IIS/ASP.net? It seems to be quite a problem for websites with
local/remote access while still requiring the required username. Or is ADFS
the MS recommended solution?

many thanks for your help

Graham

 

[Joe Kaplan \(MVP - ADSI\)]

Basic auth should be used with SSL. Basic authentication is an HTTP defined
protocol; MS can't change it. They just support it in their browsers and
servers and allow it to interop with Windows logins. If you want
encryption, just use SSL. Any serious application that requires
authentication should use SSL anyway, as forms-based authentication is
subject to the user's cookie being stolen in transit which is just as bad.
Some security experts suggest that NTLM without SSL is more vulnerable that
Basic auth with SSL.

There is a nice set of links on ADFS here on the MSDN Identity portal:
http://msdn.microsoft.com/security/identityaccess/default.aspx
ADFS also requires SSL, FWIW.

ADFS is generally intended to be used for federation, which is a
standards-based technology intended to allow multiple different
organizations to access each other's web applications using their own
credentials. An example might be using your company's AD credentials to
sign in to your 401K provider's website.

It may take a little digging to see how you could actually use ADFS to
implement your application, as your scenario isn't one of the key ones they
tend to map out in the example guides. It would certainly work though.

Basic auth with SSL is your path of least resistance too.

Joe K.

 

[Graham Lloyd]

Thanks again for the info. That is an excellent paper and ADFS looks like
the way of Identity management in the future years. However, in the short
term I have managed to get the requirements changed to either use Windows
Authentication for all internal user sites and Forms for any sites with
remote users (forcing all users to login). SSL was given the thumbs down as
remote users may not always be on the same PC and therefore not have the
client certificate.

I will however build a prototype and try and implement ADFS to see how much
work is in involved just out of interest.

cheers

Graham

 

[Joe Kaplan]

SSL does not require a client certificate. Typically, you just use SSL with
a server certificate to encrypt the traffic between the browser and server.
This is important to prevent the user's credentials (either plaintext
password or their login cookie) from being stolen. I'd definitely suggest
using it.

Good luck with ADFS. The step by step guide can be really helpful (although
a little frustrating too if you get off the path).

Joe K.

 

[Graham Lloyd]

Thanks for the info. I always assumed SSL required a client certificate to
authenticate. I will definately look into it.

However, my clients like the idea of a custom login page rather than the IIS
popup login box. From what I've read (which isn't a great deal) that isn't
possible is it?

cheers

Graham

 

[Joe Kaplan]

There are two parts to SSL, which is why this can be confusing. There is
the standard "server cert only" implementation which provides channel
encryption and authentication of the server. Optionally, the client can
provide a client certificate to authenticate it as well. In the case I was
discussing, I was simply suggesting using SSL in order to get an encrypted
HTTP channel, so the server-only implementation would suffice.

ADFS actually does support client certificate authentication for accounts in
the Windows/AD store, but that is really isn't that important to this
conversation.

ADFS supports a component called the federation service proxy which is
designed to provide forms-based login services to clients on the public
internet. It is possible to use ADFS with both the proxy and the regular
federation server (which provides login via IWA, basic or client certifiate
auth), so that you would get the exact scenario you wanted (forms for
extranet users, IWA for internal). It is also pretty easy with ADFS to
store external users in an ADAM database instead of AD, so if you want to
provide login to external people, you don't have to put them in your AD. Of
course, it is a federation system, so ideally you would just establish a
federation trust with the external users' organization and let them
authenticate themselves.

HTH,

Joe K.