I know that you can't use both Windows and Forms authentication within the same ASP.NET application. I also know that there have been other "Posts" regarding this topic, but I can't seem to find one that answers my question. First, the problem: Idealy, I'd
like to have my application use Windows authentication when being used as an Intranet application. When running as an Internet application, I'd like to use Forms authentication. Second, the question(s): How can this be done? Can it be done? I've read (somewhere)
that you can use 2 web.config files in a single application. Is this true? If so, how is that done? Thanks,
The article Colt mentioned appears to be using Forms Authentication only. While it uses APIs for validating Windows logins, it does not, in fact, use Windows Authentication. While some might think I am splitting hairs here, I think it is a big difference to
use Forms Authentication throughout and actually use Forms sometimes and Windows Authentication sometimes. There is a way to do it and leave it truly separate. I created a sample to show you how to do this: 320105 The caveat to this example is that there is
no preauthentication for IIS, so we need to know of a way to send the client to either Forms or Windows Authentication. The sample is based on IP addresses and takes the common scenario of allowing local lan ranges (usually non-routable addresses) to use Windows
Authentication, while allowing Internet (routable) addresses to authenticate via Forms. This is not a tutorial on Forms Authentication - so you should be familiar with it before attempting to use.
Paul, I noticed today from SharpReader that you posted an article on MSDN regarding mixing of the two authentication types. I have previously visited this problem and came to slightly different conclusions than you. Its funny that you posted here, because I
was just going to email you. If your intent is only to learn the user's login, then perhaps your method would work fine. However, I think it is missing the greater benefit of truly using Windows Authentication - and that is harnessing the power of Active Directory
and your security groups. Correct me if I am wrong, but your solution is still just Forms Authentication, so you would lose all the automatic things that IIS does for Integrated Auth. Companies that have leveraged AD for all their employees want to continue
to use it without wrapping it in some sort of Forms authentication. The most common case of this seems to be having an internal application that you want to also be available for partners on the internet. You would need to move all the information that you
have stored in AD into some sort of cookie or other mechanism to start to use the roles-based framework again. Am I misinterpreting this article, or is there some simple way to continue to harness all the work that corporations have put into security groups
and such?
My article only demonstrates authenticating the user, which could be against AD, and capturing the UserName -- you can then handle roles any way you would like. You could even combine this true authentication with your WindowsIdentity work, but keep in mind
that your technique by itself doesn't actually do any authentication. So I don't see any reason why you would have to ignore the roles in AD with this, but you will certainly have to still handle the non-Windows users' roles separately. I haven't seen any
other way to "really" authenticate Intranet and Internet users at the same time, without running the application in two separate virtual directories.
Thanks, Paul Wilson, ASPInsider, MC**
For the best .NET code, examples, and tools, visit:
WilsonDotNet.com, WilsonWebPortal.com, ORMapper.net
Maybe I am missing something, but try this with your example: Add another page called test.aspx:
Now, add another tag to your web.config
Now, create the WebMgr role on your IIS server and load yourself into it (make sure to logoff/on again to have your token updated). Now, try to browse to this page directly. It gets stuck into a loop here, and you cannot utilize Windows Roles. If you take the
trouble of actually discovering these roles the user is part of (using APIs or System.DirectoryServices), and then putting them into your FormsAuth cookie (and fixing "MACHINE" prefix), this would probably work, but then you are duplicating what Windows Authentication
should be doing and you lose the nested group membership at the same time (in most circumstances). I am not trying to be negative about your solution, rather I am just trying to work through it and all the implications. I would be quite excited if this truly
delivered a seamless experience for both Forms and Windows users. I guess what I am saying is that for your solution to work, I would need to duplicate what AD is doing and stuff all that information into the FormAuth cookie since the Windows token will never
actually be checked (except by one page - winlogon.aspx). The technique I utilized truly separated the authentication (but not the application) - it checks the Windows token for some IP address ranges, and the Forms Auth ticket and cookie for ones it deems
needing manual authentication. This has the benefit of preserving everything the IIS does for you automatically as well as all your group memberships in AD with no work. You still need to take care of your Forms Auth users. However, it has a price of needing
to know which way to send the user. If I could work out a way to overcome what I am perceiving as the limitations in your solution, I would have the best of both worlds. However, I don't think this is possible. I hope I am making sense and I really don't want
this to sound as if I am blasting you, because I am not.
Of course you can't just put Windows roles in the web.config since we are using Forms authentication. You will need to handle roles separately, possibly even combining this with your work on WindowsIdentity. Also, while this is possible, let's not lose sight
of the fact that most people here on these forums that have been asking how to combine Windows and Forms authentication have just wanted the UserName. I likewise don't want to be critical of your work, as I have looked at it and been impressed with it myself,
but your technique does NOT ever authenticate the user -- it assumes a certain IP address is enough. That may be enough in many cases, but its not enough in many other cases -- I verified this for myself. All someone has to do is have the ability to get on
your intranet, either by being physically connected or wirelessly, and many many companies do allow un-authenticated computers to access their intranet. In the end, both of us are admitting that you are still going to have to handle the roles for other users,
so its very deceptive to imply that there will not need to be any code written to handle roles -- there is. I'm simply showing how to combine authentication types, real authentication without any IP assumptions.
Thanks, Paul Wilson, ASPInsider, MC**
For the best .NET code, examples, and tools, visit:
WilsonDotNet.com, WilsonWebPortal.com, ORMapper.net
I misunderstood your work then. When you say "mixed security", I take it to literally mean that Windows Authentication will be used sometimes and Forms authentication will be used other times. I also understood that you meant after I was authenticated with
Windows Auth in your example, I could start leveraging AD (and hence the mixing). I think you might have also misunderstood my work. It does indeed authenticate the user. You cannot simply bypass anything. If you somehow managed to trigger Windows Authentication
(perhaps by getting a local lan address wirelessly) and yet were not a member of the domain or IIS server, it would submit your current credentials to the domain - which would then be rejected and you would be prompted by IE to login. Assuming you pass valid
credentials it will continue on, else you will stop there with a 403 status (with 3 invalid logins or a Cancel event). You will always have to take care of the Forms Auth users, this you and I agree on. You should not have to take care of the Windows Auth
users and what I have done with the web.config would work fine with my example. Think of it this way - what you have shown compared to what Colt referenced is virtually identical. You will have to write some code to determine if the user is a Windows user,
or else use a database (or other store) to authenticate against. If they are a Windows user, then you need to unwrap their token groups and put them into the Forms cookie (or risk losing membership). It is not exactly a trivial matter to unwrap these groups,
nor a performant method if done incorrectly. If they are a Forms user, then you take their roles from the DB, but in both scenarios you are doing all the work. That is the problem, this is just Forms auth - there is no mixing at all. There are a number of
other problems as well. Suppose I am in 50 or 60 groups (not at all uncommon), I cannot fit this information easily into the cookie anymore. I could then move all my roles to the db and pare it down to only the ones that 'matter'. Then I have defeated the
purpose of AD and failed to leverage my investment in the first place by relegating roles away from AD (not to mention I now have to somehow synchronize the accounts and roles between the two). Next, what happens when I want to use delegation? It will no longer
work and you have lost your investment in AD again. The most common scenario is the intranet application being dragged out to a select vendors via the internet. Losing what AD natively does for you is a big problem for a lot of these people (even more than
they likely know), and I truly believe that they want to leverage more than just what the username is in most circumstances. Any non-trivial internal application probably uses more than just the username. I have said it before, and its ok if you think I am
splitting hairs here, but this is just not Mixing Authentication, IMO. This is Forms Authentication, no more, no less. I will not count anything as truly mixing until you are actually leveraging AD natively with no changes to accomodate Forms Auth. Anyhow,
I have been looking at this problem for sometime, and I enjoy discussing it. Thanks.
This hardly seems the place to be hashing this out, but . . . I have tested yours, and as long as I am physically connected to my company's intranet, and thus have an IP address in the right range, then that was enough to get through! My username, however,
was not remotely related to my company -- I was not authenticated. Now, as to mine, I do not have to write any code to determine if its a Windows user. The Windows user is automatically authenticated -- end of story -- nothing else to do. Unless of course
you want to add userdata that this user was a Windows user -- simple. If one also needs Windows roles, then it can be combined with your WindowsIdentity work. This is mixing Windows and Forms Authentication, since you are either authenticated by Windows (via
IIS) or your own custom ASP.NET system -- that much seems very clear. You can argue its not a native mix of Windows and Forms Authorization, which is true by default, but I have not tried to ever state it was a mixture of Authorization types. On the other
hand, testing an IP address is not Authentication of any kind at all. What we are trying to do is obviously not trivial, or there would be many examples, and there does not appear to be any system yet that perfectly combines them all, but my system does authenticate
the user automatically, and allow custom otherwise.
Thanks, Paul Wilson, ASPInsider, MC**
For the best .NET code, examples, and tools, visit:
WilsonDotNet.com, WilsonWebPortal.com, ORMapper.net
rgcazo
Member
410 Points
94 Posts
Mixing Forms and Windows Authentication
Jan 20, 2004 12:10 PM|LINK
Applications Development Supervisor
Colt
All-Star
15569 Points
1986 Posts
ASPInsiders
MVP
Re: Mixing Forms and Windows Authentication
Jan 20, 2004 12:19 PM|LINK
dunnry
Star
9098 Points
1806 Posts
Re: Mixing Forms and Windows Authentication
Jan 21, 2004 03:04 PM|LINK
Weblog
The Book
LDAP Programming Help
PaulWilson
Contributor
3715 Points
745 Posts
ASPInsiders
Re: Mixing Forms and Windows Authentication
Jan 30, 2004 07:32 PM|LINK
For the best .NET code, examples, and tools, visit:
WilsonDotNet.com, WilsonWebPortal.com, ORMapper.net
dunnry
Star
9098 Points
1806 Posts
Re: Mixing Forms and Windows Authentication
Jan 30, 2004 07:41 PM|LINK
Weblog
The Book
LDAP Programming Help
PaulWilson
Contributor
3715 Points
745 Posts
ASPInsiders
Re: Mixing Forms and Windows Authentication
Jan 30, 2004 07:53 PM|LINK
For the best .NET code, examples, and tools, visit:
WilsonDotNet.com, WilsonWebPortal.com, ORMapper.net
dunnry
Star
9098 Points
1806 Posts
Re: Mixing Forms and Windows Authentication
Jan 30, 2004 08:37 PM|LINK
Weblog
The Book
LDAP Programming Help
PaulWilson
Contributor
3715 Points
745 Posts
ASPInsiders
Re: Mixing Forms and Windows Authentication
Jan 30, 2004 09:39 PM|LINK
For the best .NET code, examples, and tools, visit:
WilsonDotNet.com, WilsonWebPortal.com, ORMapper.net
dunnry
Star
9098 Points
1806 Posts
Re: Mixing Forms and Windows Authentication
Jan 30, 2004 10:33 PM|LINK
Weblog
The Book
LDAP Programming Help
PaulWilson
Contributor
3715 Points
745 Posts
ASPInsiders
Re: Mixing Forms and Windows Authentication
Jan 31, 2004 01:54 AM|LINK
For the best .NET code, examples, and tools, visit:
WilsonDotNet.com, WilsonWebPortal.com, ORMapper.net