I want to combine Forms username/password authentication with the option to also log in through your Intranet LOGON_USER account without a password.

So on my page you can choose to either use the Login control or click a button to say Log me in as the person Logged into this computer i.e. Request.ServerVariables["LOGON_User"]

The ValidateUser() function only has 1 method for (username, password), I would like to override this method to have ValidateUser(string LogonUser), does anyone know how to do this?

I have done it before in ASP.NET 1.1 by creating a new SitePrincipal and SiteIdentity (adapted from 1st book) which inherited from the original interfaces, is there an easier way to do this in .NET 2?


Steve

I don't think there's an easier way in 2.0. But instead of using the base class for wiring up the security, Marco should have used the AuthenticateRequest event in global.asax.cs. That would have eliminated about 80% of the support problems people had with ThePhile.

In AuthenticateRequest you can inspect the user's Windows identity, and if it's good you can make him a forms authentication ticket. Otherwise you need to direct him to the login form. Inside the login form you can make him a ticket if he passes the test.

I'm not sure if you have to make a custom Identity and Principal. Most people do that in cases like yours, but I think a GenericIdentity and Principal may meet the minimum requirement. I like to store extra info about the user in a custom identity and I store group access rights in the principal.

Eric

I have got it working using the following simple code, Global.asax adds the Windows user if they have not been to the site before, and Login.aspx allows the user to either click a box to say they want to authenticate as the user logged on or they are free to enter a username and password using the forms Login Wizard.



Authentication (Login.aspx on same page as LoginWizard):

function AuthenticateWindowsUser{
   string LoggedOnUserName = Request.ServerVariables["LOGON_USER"].ToString();
   if (Membership.FindUsersByName(LoggedOnUserName).Coun t > 0)
   {
      FormsAuthentication.RedirectFromLoginPage(LoggedOn UserName, false);
   }
}




Create User (global.asax):

void Session_Start(object sender, EventArgs e)
{
    // Code that runs when a new session is started
    string LoggedOnUser = Request.ServerVariables["LOGON_USER"];
    if (Membership.FindUsersByName(LoggedOnUser).Count == 0)
    {
        string DefaultPassword = "¬áé4óÓg€$*"; //something obscure here
        string EmailAddress = "[email protected]";
            MembershipCreateStatus status;
            MembershipUser mu = Membership.CreateUser(LoggedOnUser, DefaultPassword, EmailAddress, null, null, true, out status);
            if (status != MembershipCreateStatus.Success)
            {
                throw new ApplicationException(status.ToString());
            }
            else
            {
                ProfileCommon pc = (ProfileCommon)ProfileBase.Create(mu.UserName, true);
                pc.FirstName = "test";
                pc.LastName = "tester";
                pc.WindowsUser = true;
                pc.Save();
            }
    }
}





Steve

> Request.ServerVariables["LOGON_USER"]

I don't feel real comforatable with this code. It looks like it'd be easy to spoof. You need to let Windows tell you if the user has been authenticated. Look for the WindowsIdentity to tell you this.

Then you can look up the user, and create the Identity and Principal. Since the Principal holds a reference to the identity you only need to keep the principal. I typically put it in the cache with a High priority to avoid having to look him up on each page hit. Our company uses a secure web service to authorize users and this is a little slow. But I definitely have to validate him on each page hit in AuthorizeRequest (I verify that I have his principal - if it's not in the cache I have to look at his Windows Identity again and fire off a new request to the web service to see if he's a valid user and to get his groups).

Then, after creating the principal, you need to create a Forms authentication cookie (called a ticket) and put it in his cookie collection. This will make the Forms auth system think he's logged-in.

I wish it weren't so complicated, and it takes a lot of manhours to get this code right and test it completely. I use a lot of logging when I'm developing the code, and then I disable it later. Once the code works, I only keep a minimum amount of logging to help me track down problems. Too much logging can be a security concern in this kind of code.

Eric

Check this link for more info on mixed mode asp.net authentication:

http://aspalliance.com/553

I wish it were easier! There's also some links referenced in that article that you should check out.

Eric

Thanks thats an excellent article. However my problem is slightly different in that I cannot access the Active Directory Roles, as it is such a huge corporate address book, I don't have access to easily amend users Windows roles. So I need to maintain my Roles within the website.

I plan to base the site on Forms authentication, but also capture the Windows Logon from the WindowsPrincipal. If the user chooses to authenticate via Windows rather than by Username/Password then I shall issue an authentication ticket for them, but their username will be stored as their WindowsLogon name and I shall set a Profile value called WindowsUser = true.

Then I will only allow users to authenticate when they enter a username/password with forms authentication, if their profile also has WindowsUser(custom Profile settings) = false.

That way I can manage Roles and all type of users together in the system.

It seems a bit odd, but is the best way of managing users for such a large corporate network where you don't have access to change windows security groups yourself.

thanks


Steve

It's not your fault, but your network people need to reconsider the primary reasons for using AD in the first place. It is almost essential to use real roles in AD in a large company. Or, in ANY company that has AD and a large intranet application. To do otherwise would be running on half the cylinders.

I understand your problem and it stems from people who are not willing to delegate the proper permissions to the proper people. Either they don't know how to do it, or else they just don't want to give up any of their power.

Homegrown roles and groups handled within a DB are fine. But that's not the best way in an AD environment, especially if the user accounts are already in AD.

Sorry...this is a soapbox issue for me :-)

Eric

One of the problems of a large Intranet is getting anything done by the support company. To add/remove a user to a role involves ringing help desk and trying to explain to them what you want doing. Then it disappears into a deep hole where you hope the person at the end charged with doing the task knows what they are doing.

In reality this is a nightmare and used to not be possible for amending AD roles. I'm not sure if this has changed recently, I will check. However compared with being able to change roles and permissions within the website, the latter is much easier/faster to manage, where as Help desk could take days to add a user and then still get it wrong. That's the reality of the situation here..




Steve

We had similar problems at our company so we wrote a custom Security Request application. This automates the whole request and approval mechanism to have changes made to users and roles. My original goal was to have the application make the final changes directly in AD after the proper approving official has made the approval within the application. However, our security team was gunshy to let me do that, so we agreed to give the helpdesk personal a small GUI that lets them make the changes that have made it through the request/approval process.

It used to take several days to load a new user and assign him roles and groups (we use both roles and groups), but now it takes only a matter of hours unless key people are on vacation. Even then, most of the approvers log in to the web application from the Internet even when they're out of town. Once they log in they're presented with a work queue that shows them what they need to do (not just security related, but this shows all business tasks they have to accomplish). We've developed this over a period of years and it works well now.

Eric