Re: Mixed Mode Authentication in .net 2.0
- From: "Joe Kaplan" <joseph.e.kaplan@xxxxxxxxxxxxxxxxxxxxxxxx>
- Date: Wed, 23 Aug 2006 21:18:34 -0500
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.
--
Joe Kaplan-MS MVP Directory Services Programming
Co-author of "The .NET Developer's Guide to Directory Services Programming"
http://www.directoryprogramming.net
--
"Graham Lloyd" <gilly1409@xxxxxxxxxxx> wrote in message
news:uHN32uxxGHA.3400@xxxxxxxxxxxxxxxxxxxxxxx
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" <joseph.e.kaplan@xxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:O23fu2rxGHA.1304@xxxxxxxxxxxxxxxxxxxxxxx
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.
--
Joe Kaplan-MS MVP Directory Services Programming
Co-author of "The .NET Developer's Guide to Directory Services
Programming"
http://www.directoryprogramming.net
--
"Graham Lloyd" <gilly1409@xxxxxxxxxxx> wrote in message
news:eXoSvHoxGHA.3568@xxxxxxxxxxxxxxxxxxxxxxx
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 (MVP - ADSI)" <joseph.e.kaplan@xxxxxxxxxxxxxxxxxxxxxxxx>
wrote in message news:%23lDRPlZxGHA.1364@xxxxxxxxxxxxxxxxxxxxxxx
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.
--
Joe Kaplan-MS MVP Directory Services Programming
Co-author of "The .NET Developer's Guide to Directory Services
Programming"
http://www.directoryprogramming.net
--
"Graham Lloyd" <gilly1409@xxxxxxxxxxx> wrote in message
news:%23lKg53YxGHA.4700@xxxxxxxxxxxxxxxxxxxxxxx
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)" <joseph.e.kaplan@xxxxxxxxxxxxxxxxxxxxxxxx>
wrote in message news:eIuWnzUxGHA.2120@xxxxxxxxxxxxxxxxxxxxxxx
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.
--
Joe Kaplan-MS MVP Directory Services Programming
Co-author of "The .NET Developer's Guide to Directory Services
Programming"
http://www.directoryprogramming.net
--
"Graham Lloyd" <gilly1409@xxxxxxxxxxx> wrote in message
news:%23UgWNcMxGHA.2352@xxxxxxxxxxxxxxxxxxxxxxx
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
.
- References:
- Mixed Mode Authentication in .net 2.0
- From: Graham Lloyd
- Re: Mixed Mode Authentication in .net 2.0
- From: Joe Kaplan \(MVP - ADSI\)
- Re: Mixed Mode Authentication in .net 2.0
- From: Joe Kaplan \(MVP - ADSI\)
- Re: Mixed Mode Authentication in .net 2.0
- From: Joe Kaplan
- Mixed Mode Authentication in .net 2.0
- Prev by Date: RE: Forms Authentication Problem
- Next by Date: Re: How to run as in a deamon
- Previous by thread: Re: Mixed Mode Authentication in .net 2.0
- Next by thread: ADAM & AzMan Problem ("The parameter is incorrect:)
- Index(es):
Relevant Pages
|
|
