Mixed Mode Authentication
page 2 of 2
by Paul Glavich
Average Rating: This article has not yet been rated.
Views (Total / Last 10 Days): 49434/ 34

Mixed Mode Authentication - Page 2

Step 2 - Extracting the User's Role Information

Extracting the user's role information involves a bit of reflection magic. Bascially, we use reflection to look inside the principal object that is provided to us by Windows/IIS when the user is authenticated. Please note that this involves reflecting over specific properties of the principal object and is not guranteed to work in future versions of .NET. It does work and has been tested in production environments using .NET Version 1.1 (v1.1.4322).

The most logical place to extract the role information from the principal is the 'Application_AuthenticateRequest' event. Briefly, we look at a particular string array within the principal to extract any role information from the principal. There are some tricks to watch out for, which we will cover shortly. Listed below is some code that will extract the role from a principal object.

private static string[] GetRoles(IPrincipal princ)
 Type type = princ.GetType();
 // Note: This code sets the 'MAGIC_NUMBER' field of the principal object.
 FieldInfo field2 = type.GetField("MAGIC_NUMBER", 
   BindingFlags.Instance | BindingFlags.NonPublic | BindingFlags.Static);
 field2.SetValue(princ,40);  // This value can be any number but defaults to 23.

 princ.IsInRole("DummyRole");  // This call is required so that the subsystem goes 
                               // and retrieves a list of roles.
 // Without this call, the principal object does not contain any roles in its internal
 // variables, and thus the code below that uses reflection to get the value of this variable
 // will fail and return NULL.
 FieldInfo field = type.GetField("m_roles", BindingFlags.Instance | BindingFlags.NonPublic);
 String[] roles = (String[]) field.GetValue(princ);
 return roles;  

And we obviously need to call this routine from the 'Application_AuthenticateRequest' event as in the code shown below:

protected void Application_AuthenticateRequest(Object sender, EventArgs e)
 WindowsIdentity ident = WindowsIdentity.GetCurrent();
 WindowsPrincipal wind_princ = new WindowsPrincipal(ident);
 string[] roles = GetRoles(wind_princ);

You will notice in the 'GetRoles' method above, we set a 'MAGIC_NUMBER'. This number determines how many roles the user can have before the roles are stored in a hashtable in the principal object, instead of a string array. This is done for performance reasons, but the important part is that if your intranet users are on a domain and happen to have more than this 'MAGIC_NUMBER' number of roles, then the string array you are getting the users roles from will be empty. By default, this 'MAGIC_NUMBER' is set to 23. The code in the method above provides the ability to change this 'MAGIC_NUMBER' to any value you like. For our purposes, we will change it to something higher to make sure we get all the roles in our string array.

Step 3 - Simulating a Valid Forms Authentication Ticket and Supplying the User's Roles

Now we need to put all this together. We need to take the role information we have extracted from the principal and pass it over to our forms authentication entry point application, telling that entry point we have a valid autenticated user.

The Windows authentication entry point site has extracted the role information. Now it only needs to create a forms authentication ticket, store the roles in the user data, and issue the ticket. The ticket must have the same path and name across both the forms authentication site and the windows authentication site. The code below shows the code that should be placed in the 'Global.asax - Application_AuthenticateRequest' event for the storage of the roles and the redirection.

protected void Application_AuthenticateRequest(Object sender, EventArgs e)
 // NOTE: Because we are encrypting some information and passing it to another site, 
 // the MACHINE.CONFIG file needs to have the <machinekey> element set to a static 
 // value. By default, this value is autogenerated for each web application on the 
 // machine and will therefore fail if you try and pass encrypted tickets/data between
 // web apps.
 WindowsIdentity ident = WindowsIdentity.GetCurrent();
 WindowsPrincipal wind_princ = new WindowsPrincipal(ident);
 string[] roles = GetRoles(wind_princ);   // See method above for 
                                          // implementation of this method
 string roleData = String.Join(";",roles);
 FormsAuthenticationTicket ticket = 
   new FormsAuthenticationTicket(1,
 string encTicket = FormsAuthentication.Encrypt(ticket);

 // NOTE: The name of the HttpCookie must match what the FormsAuth site expects.
 Response.Cookies.Add(new HttpCookie("YourCookieName",encTicket));
 // Ticket and cookie issued, now go to the FormsAuth site and all should be well.

As you can see, we encrypt this ticket using the forms authentication standard routines. For this to work across applications, modifications must be made to the machine.config file to ensure encryption keys are not auto-generated for each application. The modification required is shown below:

<!--     Your old machine.config entry will 
                               resemble the line below  -->
<!--     <machineKey validationKey="AutoGenerate,IsolateApps" 
      decryptionKey="AutoGenerate,IsolateApps" validation="SHA1" /> -->

<!--     You NEED to change that entry to resemble 
     something like the line below. Note: The validationKey/decriptionKey 
     should be your own  -->

Lastly, the 'Global.asax' file in the forms authentication entry point site must be modified so that the 'Application_AuthenticateRequest' event knows how to decipher a valid ticket issued by the Windows authentication entry point site and assign these roles to the current principal. The web.config of this site must also be setup to have matching attributes (i.e., name) as what the Windows authentication site is issuing. The code below demonstrates this :


<authentication mode="Forms">
    <forms name="YourCookieName"   <!-- This cookie name matches what 
                                        the Windows Auth site creates  -->
       path="/"     <!-- This same path as what the Windows auth site uses 
                         when creating the cookie/auth ticket  -->

 <deny users="?" />   <!-- Only allow authenticated users. Add your 
                       application and domain specific access roles here -->

Application_Authenticate Event (Forms Auth site)

protected void Application_AuthenticateRequest(Object sender, EventArgs e)
 bool cookieFound = false;

 HttpCookie authCookie = null;
 HttpCookie cookie;

 for(int i=0; i < Request.Cookies.Count; i++)
  cookie = Request.Cookies[i];

  if (cookie.Name == FormsAuthentication.FormsCookieName)
   cookieFound = true;
   authCookie = cookie;

 // If the cookie has been found, it means it has been issued from either 
 // the windows authorisation site, is this forms auth site.
 if (cookieFound)
  // Extract the roles from the cookie, and assign to our current principal, 
  // which is attached to the HttpContext.
  FormsAuthenticationTicket winAuthTicket = 
  string[] roles = winAuthTicket.UserData.Split(';');
  FormsIdentity formsId = new FormsIdentity(winAuthTicket);
  GenericPrincipal princ = new GenericPrincipal(formsId,roles);
  HttpContext.Current.User = princ;
  // No cookie found, we can redirect to the Windows auth site if we want, 
  // or let it pass through so that the forms auth system redirects to 
  // the logon page for us.

Final Considerations

The forms authentication site must also contain code for users who are logging in via the standard logon page. Typically, you would assign a single role of low privilege to identify the user as a non-intranet user (e.g., external to the organization) and assign that role to a principal and attach it to the HttpContext in similar fashion to the code above.

At this point, your application can make role checks against the principal attached to the HttpContext in a standard manner. The application does not have to worry about where the user came from--standard role checks are all that is needed--, and it can therefore tailor the user experience based on the different roles.


The technique I have described here is not trivial and requires reasonable knowledge of the forms authentication system that .NET uses. The advantage is great though. You can now let both intranet users and external parties access the same application in a consistent manner with the standard role-based access checks being applied to determine a user's functionality and origin. The code to do this is not great and the setup can be tricky, but this technique does work and is currently being used in a number of ways within our organization to great effect.

If you are having difficulty with the concept or its implementation, I can be contacted at glav@aspalliance.com.

Happy Coding...

View Entire Article

User Comments

Title: MVC3 and IIS7   
Name: Paul Glavich
Date: 2012-02-08 5:36:56 PM
Hi Joe and Jeff,
It has been a very long time since I revisited this code. If I get time I will try and get it updated for the latest tech. The basic cookie principles are the same but the mechanics of MVC3/IIS7 are what would be causing it to not work.
Title: MVC3 and IIS7   
Name: Joe
Date: 2012-02-08 10:40:11 AM
I agree with Jeff. :)
Title: IIS 7   
Name: Jeff
Date: 2012-02-03 11:31:55 AM
What are the chances of getting this article updated to 2012? I find that this solution doesn't work with IIS 7 and MVC 3.
Title: HttpSessionState.Timeout   
Name: Vladimir Kelman
Date: 2009-01-05 8:08:56 AM
Hi Paul! What happens in your solution when a user which was successfully authenticated does not do anything for a time longer than HttpSessionState.Timeout? I assume that if user clicks to any internal link/button after Session was expired, she is redirected to a Form login screen and it happens regardless of was a user initially authenticated through a Windows site or through a Form site. Isn't it a problem?
Title: Re: SharePoint and Office Integration   
Name: Paul Glavich
Date: 2007-10-07 8:01:34 AM
Hi Philip,
I am not too familiar with the Sharepoint means of authentication but if office uses only integrated, it will work if the user is a member of the authenticated domain, however they may have to eneter their domain credentials as well, so the single sign on wont exactly work. You would have to intercept the auth mechanism's for both to be able to achieve the single sign on and emulate the forms auth cookie.
Title: SharePoint and Office Integration   
Name: Philip Waters
Date: 2007-10-03 2:23:34 PM
In sharepoint a web authenticated user can click on a document that is launched in the local Office Application.

For intranet users that authenticate using windows integrated authentication, i assume they will not have to authenticate a second time when they launch a document.

Is that correct?

I assume for IE 7 they will have to have *.app.domain in their trusted or local intranet sites for authentication passthrough.

Since all authentication ultimately goes through forms authentication, i'm concerned that office integration will not work seamlessly because MS Office doesn't utilize authentication that occured through a form.
Title: Re: Magic Number Issue   
Name: Paul Glavich
Date: 2007-09-03 7:45:13 AM
Hi Murali,

This code has not been tested under 2.0 and I do know that the magic number does not explicitly exist as an internal member within .Net 2. I have not yet had a chance to revap this code to 2.0 but a little playing with reflector should be able to yield the effect you desire. So I have no immediate resolution to the issue for .Net 2 is your ultimate answer.
Title: Magic Number ISSUE   
Name: Murali
Date: 2007-08-30 5:05:22 PM
I have implemented Mixed Authentication in 1.1 which works fine but i am having issue when i migrate the App from 1.1 to 2.0 the Magic Number returns nothing. Do you have any solution for this issue.

Thank you
Title: Re: Problem   
Name: Paul Glavich
Date: 2007-08-28 11:39:41 PM
Hi Monir,

Did you create the virtual directory as a sub-dir of the main site? (ie. and not as a virtual directory on its own).
Title: Problem   
Name: Monir
Date: 2007-08-28 1:50:09 AM
Hi,I am having Problem in the web site for FormAuthentication.When I entered into the Windows Authentication Site it redirects to the Form Authentication Site with cookie 'CMUCookie'.
FormsAuthentication.FormsCookieName equals to also 'CMUCookie'.But the problem is that the codes below in the global.asax in the Form Authentication Site does not execute. That is cookieFound =false. why this is happening?
I have made the virtual directory as u directed.

if (cookie.Name == FormsAuthentication.FormsCookieName)
cookieFound = true;
authCookie = cookie;
Title: Error   
Name: Ajeet
Date: 2007-07-10 9:15:18 AM
After going thru the code, it provides an error that in the global.asax of windows application "field2.SetValue(princ,40);" it throwing a null exception handling error
can you explain it
Thanks in advance
Title: Re: Single Entry   
Name: Paul Glavich
Date: 2007-05-07 5:45:53 AM
Hi Tony,

You are correct. If windows auth is used and the user is NOT a member of the domain, the credentials prompt will get shown by IE. Not much you can do to get around it. I guess you could write a handler to perhaps check for some specific header information (if you could inject it) or query information, and if present, redirect appropriately, but that implies some control over the users browsing experience which not many people have (eg. intranet users may always have a "organisation" cookie carried along that you could check for).
Title: Single Entry   
Name: Tony
Date: 2007-05-03 6:13:29 AM
Hi, I was directed here from the ASP.NET forums and unless I have miss understood (hopefully) this is not the right spot for me.

I would like a similar behaviour, but with a single entry point as my users can't be expected to know whether they are authenticated to a domain or not.

Users hitting a web set-up for Integrated Windows Authenticated would surely get a login prompt no?
Title: re: HELP!!   
Name: Paul Glavich
Date: 2007-03-25 9:30:49 PM
Hi Non IT person,

If your organisational policy is to NOT use anonymous access (which forms based auth requires) and to only use Windows auth, it makes this approach not really possible. IIS is the first port of call for requests and if it mandates windows auth only, then thats what you get.
Title: re: same thing in ASP   
Name: Paul Glavich
Date: 2007-03-25 9:28:38 PM

Well technically its possible, but with a great deal of difficulty and COM interop. I have not done this and it would require some serious investigation work to make it so. My advice... dont do it.
Title: HELP!!   
Name: Non IT person
Date: 2007-03-20 10:43:28 PM

I am trying to install an application at work which requires a mixed mode authentication... although my office server only allows for single (windows authentication). As a consequence the IT department are saying that I am unable to install the application because a mixed mode authentication process will compromise company security. I do not have an IT background and would therefore like to know whether there is a possibility to install the application without compromising company security???

Title: very good   
Name: madhu
Date: 2006-11-30 12:28:40 AM
its very nice to read ,article of this stuff
Title: same thing in ASP   
Name: Naman
Date: 2006-11-28 6:19:54 AM
Hi Paul,

I need same thing in ASP without using .NET technology. is this possible???
Title: Re: .NET Version 2.0   
Name: Paul Glavich
Date: 2006-10-15 9:43:25 PM
I haven't done much investigation with .Net 2.0 and this technique and the reflection part that you mentioned does not work is no surprise. However, if you -know- that the number of roles will remain low, then you dont really need to do this. This reflection was to cater for the number of roles that is catered for by default. Any more roles than the 'magic_number' incurs a performance hit that is dealth with differently. I'd have to crack open reflector and have a look to see what the appropriate reflection technique (if any) is required for .Net 2.0. Easiest way to tell if you need to do it is define a user with a large amount of roles (say > 50 maybe more), then use this technique to get the roles (without the MAGIC_NUMBER code) and see if you get all the roles back.
Title: .NET Version 2.0   
Name: Brian
Date: 2006-10-13 10:45:19 AM
I am trying to do pretty much exactly what you've written about except I'm doing it with .NET Version 2.0 instead of .NET Version 1.1 (v1.1.4322). My problem is when I try to GetRoles(IPrincipal princ)
FieldInfo field2 = type.GetField("MAGIC_NUMBER", BindingFlags.Instance | BindingFlags.NonPublic | BindingFlags.Static);
This line of code returns field2 as null. I'm not sure if this is a Version 2.0 problem or just something else, I suspect that its a problem with trying to do it in Version 2.0 . I'm fairly inexperienced with all of this and was looking for a little help???
Title: Is the reverse possilbe   
Name: Amir
Date: 2006-09-15 1:20:11 PM
Lets say there a two web applications. One that uses windows authentication and the other that uses just annonymous. For the one that uses annonymous access we have a form that authenticates the user. Is it possible to redirect the user to the application that uses windows authentication without having to re-enter the user credentials from that application(annonymous app)? Both application sits in the website directory
Title: coder   
Name: adam
Date: 2006-08-29 4:49:41 PM
What do I have to do finally in the
Application_Authenticate Event (Forms Auth site) if the cookie is found? My site bounces me out again to the login form. I tried using:

FormsAuthentication.SetAuthCookie(formsId.Name, false);

and this seems to get the user to the windows login site original request. But is this right? Thanks in advance.
Title: Re: Charles Bretana Jr   
Name: Paul Glavich
Date: 2006-08-21 2:42:01 AM
Ofcourse. If you simply use cookies and a form based scheme to do the authentication, the windows roles dont really have any effect. If you get the user to logon via the windows auth site, you can check for the existence of a particular role, if it does not exist, then redirect to the forms auth site. Alternatively, just go straight to the forms authentication site and get them to log in. This can issue a cookie based on what they log in as and is independent of their windows identity. As long as you use forms based authentication via cookies, you should be fine.
Title: Other way around ?   
Name: Charles Bretana Jr
Date: 2006-08-19 1:09:25 PM
This may be exactly what I'm looking for, but befopre I go down this path, can you tell me if it can also be set up to work the other way? That is, as I understand it a way for a site to accept users currently logged on to their workstations, and ALSO accept those who are not, by allowing them to provide credetials via a logon form.

My requirement, otoh, is to do that, but also allow someone who IS authenitcated via Windows security to provide DIFFERENT credentials via a logon form (like the "run as" item in the Windows popup menu) and thereafter operate the web application under the credetials they provided, even though they are still logged on at their workstation under the original (different) credentials.

Use case: A Supervisor walks over to a worker bee's desk and wants to do something tha tthe worker bees credentials are not authorized for...

Can the design outlined here solve this problem as well ?
Title: Mr   
Name: Tej
Date: 2006-07-27 11:05:01 AM
Is this mixed mode authentication technique valid for asp.net 2.0?
Title: Window auth within Forms auth Question   
Name: Brian
Date: 2006-07-12 12:05:32 PM
I have application “A” that uses forms authentication and is used by internet users and intranet users. All users will be passed to a login application “B” that uses forms authentication and a database for roles then redirected back to application “A” after authentication. (users may have different roles depending on application) I don’t want intranet users to physically login if already logged onto the intranet network. Question: In the forms based login application “B”, can I get the user.identity.name using windows authentication or some other manner? If user.identity.name is found (user logged onto intranet) look it up in database for roles, if user.identity.name not found or not authorized for application “B” give them a login screen for forms authentication. Once authenticated and roles found redirect to application “B”.
Title: Cookieless Authenticatio   
Name: Robert
Date: 2006-06-21 12:47:30 PM
I need to implement a solution like this but I'm using cookieless="UseDeviceProfile". Is this still possible to use this solution or do I have to find another way?
Title: vb   
Name: justin
Date: 2006-05-18 10:08:03 AM
Is there any way someone could show me this method in VB?
Im writing my asp.net site with VB not C#
Title: Reply to all   
Name: Rajesh
Date: 2006-03-31 12:43:02 AM
It was very useful for me...
Title: Just What I Needed   
Name: John Morrill
Date: 2006-02-06 9:59:45 PM
This article was just what I needed. I my case we had a requirement that internal users should be able to access the application using Windows Authentication. Furthermore, internal user should not be prompted for their user name and password.

The problem is that Windows Authentication usually uses NTLM with Internet Explorer to automatically obtain the user credentials. Our application is on a web farm front-ended by a load balancer, but NTLM can not be used through a load balancer.

NTLM uses a persistent connection between the browser and the server. If NTLM is used with a load balancer that pools connections to the server, strange things will happen. What we needed was a load balancer friendly solution.

I used your example code, but instead of having MyWinAuthSite as a sub-directory of the MyFormsAuthSite, I was able to make it work on a different server altogether.

In your article, you state:

The reason for this is that both applications will need to have the same HOST name. Cookies are generated and named according to the host name they apply to. Specifying the same cookie name in code, but using different host names will cause two different cookies to be generated because of the different host names.

This is true, but the work around it to specify a value for the Domain property of the cookie. If you have to different sites named, MyWinAuthSite.contoso.com and MyFormsAuthSite.contoso.com, you can pass a cookie from MyWinAuthSite to MyFormsAuthSite by specifying “contoso.com” as the Domain when you create the cookie.

There is a catch. You can not use Sliding Expiration with the Forms Authentication ticket you create on MyWinAuthSite. In order to update a cookie with the domain value set, you must specify the Domain property in the server side code that updates the cookie. Since there is no way to specify to the Forms Authentication module the setting of the Domain property, there is no way for it to update the cookie.

If y
Title: Its also possible to do a forms authentication against a windows domain   
Name: Phil
Date: 2005-09-20 2:12:08 AM
Great article, I recently used it to implement an Intranet/Extranet solution for a client where we needed to allow intranet users extranet access as they wanted to access the site from home without but still wanted to use their Domain details.

I combined the solution presented here with the domain authentication DLL from http://www.ondotnet.com/pub/a/dotnet/2003/01/20/formsauthp2.html

and was able to allow intranet users to authenticate seamlessly while at work, then from home could use forms login using their domain account.
Title: Anonymous Access reply   
Name: Gaset
Date: 2005-07-22 1:46:29 AM
Ok, thank you. Now the matter is clear.
Title: Anonymous Access reply   
Name: Paul Glavich
Date: 2005-07-22 12:02:54 AM

One of main issues will be the fact that the user may get prompted with a domain logon depending on their browser settings if going to the auth site. This is kind of out of your control. Your initial suggestion of using the 401 error page may work, but only after the attempted negotiation.
Title: Anonymous Access reply   
Name: Gaset
Date: 2005-07-21 9:02:12 AM
Ok, thank you in any way. But this is not the point in my case. Entry point for both auth and not auth users must be the same, because there is no way of distinguishing them before the proper logging in. I just cannot tell auth user from not auth before their running through Windows auth application. That's it.
Title: Anonymous Access reply   
Name: Paul Glavich
Date: 2005-07-21 7:48:55 AM

I think I have mis-understood what you were after. If you have completely anonymous users, then dont bother sending them to the windows auth-site. Give them a link to the forms auth site only. Why bother with the Windows auth entry point? They are both only meant to gather auth info for the same app and it all gets encapsulated into a formsidentity anyway.
Title: Anonymous Access reply   
Name: Gaset
Date: 2005-07-21 7:01:54 AM
Paul, in any case execution won't reach this event hadler, because IIS will not authenticate anonymous user and access will be denied.
Thank you.
Title: Anonymous Access reply   
Name: Paul Glavich
Date: 2005-07-21 6:57:47 AM

Yes, I meant for the Windows Auth site only.
Title: Anonymous Access reply   
Name: Gaset
Date: 2005-07-21 5:25:22 AM
>> >>Access will be denied,isn't it?
>>To the windows site yes, but you can provide a standard >>login form on your forms auth site for them
>>to login.
But, as I have understood, anonymous user won't be able to pass Windows auth and won't get to Forms auth site... He will be displayed 401 error page.
And thus Application_AuthenticateRequest event won't be fired for Forms auth site. Or do you mean Application_AuthenticateRequest event handler for Windows auth site?
Title: Anonymous Access reply   
Name: Paul Glavich
Date: 2005-07-20 11:32:52 PM
Hi Gaset,

>> Access will be denied,isn't it?
To the windows site yes, but you can provide a standard login form on your forms auth site for them to login.

>> And if I want do redirect this user to the forms authenticated web site (without creating authentication cookie), what will be the best option? I assume that it is reasonable to set redirection in custom error page that is set in IIS. Will it be fine?

Well it will work, but I would be inclined to do it in the Global.asax
- Application_AuthenticateRequest event using some code.
Title: Anonymous Access   
Name: Gaset
Date: 2005-07-20 3:43:42 PM
And what if anonymous (not authenticated by Windows) user will try to login? Access will be denied,isn't it? And if I want do redirect this user to the forms authenticated web site (without creating authentication cookie), what will be the best option? I assume that it is reasonable to set redirection in custom error page that is set in IIS. Will it be fine?
Title: Developer   
Name: Oliver
Date: 2005-05-27 4:28:41 PM
Instead of doing reflection to copy all windows roles. The Generic Indentity all ready carries all those roles and can be used by casting it to windowsidentity and then to verify the roles. I think .Net Framework would allow the retrieval of roles with GetRolesForUser(...).

Public Shared Function IsInRole(ByVal principal As IPrincipal, ByVal role As String) As Boolean
Dim isValidRole As Boolean = False

If Not IsNothing(principal) Then
'Check if Role is on custom roles
If TypeOf principal Is GenericPrincipal Then
isValidRole = CType(principal, GenericPrincipal).IsInRole(role)
End If

If Not isValidRole Then
If TypeOf principal.Identity Is WindowsIdentity Then
Dim currentWindowsPrincipal As WindowsPrincipal
currentWindowsPrincipal = New WindowsPrincipal(CType(principal.Identity, WindowsIdentity))

isValidRole = currentWindowsPrincipal.IsInRole(role)
End If
End If

End If

Return isValidRole

End Function
Title: EASY TO GET   
Date: 2005-03-01 2:17:25 AM
Especially re: querying roles from a Wind
owsPrincipal. I had some different code that I was using for something like that whereby I grabbed
an array of field values from the WindowsBuiltInRole enum and looped through them checking:
Title: Re: Why we need two entry point   
Name: Paul Glavich
Date: 2005-01-29 12:52:14 AM
Having 2 entry points, IMHO, is a much cleaner way of dealing with the 2 separate authentication mechanisms. Also, under IIS5/5.1 (not sure about IIS6, allowing anonymous users will take precedence over the windows authentication which would never get done, where Anonymous auth is enabled so you would never get the benefit of the windows specific roles and be able to authorize against them.

I am curious if you have even done this and got it to work successfully.?
Title: Why we need two entry point   
Name: David Cao
Date: 2005-01-27 1:47:50 AM
Why we need two entry point?
another solution is :
1. In IIS, use windows authentication and allow anonymous access.
2. In Web Config, use windows authentication and allow anonymous access.
3. Use windows authentication to authenticate windows users. For anonymous users(Request.IsAuthenticated is False), redirect them to login page and authenticate them against database or other resources. Then build GenericIdentities and GenericPrincipals for them (we can still build FormsAuthenticationTicket cookies.). Then assign the GenericPrincipal to Httpcontext.Current.User. Later we may use iPrincipal and iIdentity to access either WindowsPrincipal or GenericPrincipal.
So only one entry point and no need to use reflection.
Title: Reply to Prerak   
Name: Paul Glavich
Date: 2004-11-09 5:50:59 AM
Prerak, you get the username via the following code below. It is referenced on page 2 of this article.

WindowsIdentity ident = WindowsIdentity.GetCurrent();
string userName = ident.Name;
Title: Question   
Name: Prerak
Date: 2004-11-08 12:30:08 PM

I understood most of the part, but I don't understand how do I get the "username" of the intranet user. What parameters do I need to change in order to get to the username.

Title: Reply to Prerak   
Name: Paul Glavich
Date: 2004-11-08 6:24:36 AM
The Windows auth site will be just a URL that you supply to your intranet users eg. http://your_intranet/winauth.aspx and the forms auth site URL is what will be redirected to from your auth site in code, AND it will also be the URL supplied to your anonoymous uses for logging on.
Title: I cant understand ...   
Name: Prerak
Date: 2004-11-07 4:41:08 PM
In regards to this article, my question could be stupid but I am fairly new to asp.net. I create a virtual directory with windows authentication. but I dont understand the flow, how does the page for windows login gets called, and how does the page for form login is called. Also in case of the windows authentication, after a user is authenticated how is the request Url called.Please suggest me.

Title: Another Alternative   
Name: Paul Wilson
Date: 2004-11-01 7:54:23 AM
Here's an article (of mine) that provides another option to integrate both forms and windows auth:

You'll still to query Windows roles, but that's very doable with code on the net. I personally think having two entry points, as you've done, is smoother but I was forced to create my single entry point solution for one gig. :)
Title: Nice stuff Paul...   
Name: Darren Neimke
Date: 2004-10-31 7:46:11 PM
Some interesting stuff in there and a few little gotcha's, especially re: querying roles from a WindowsPrincipal. I had some different code that I was using for something like that whereby I grabbed an array of field values from the WindowsBuiltInRole enum and looped through them checking:

if( myWindowsPrincipal.IsInRole( arrayOfValues[i] ) )
myArrayList.Add( arrayOfValues[i] ) ;

Yours is probably better I'll need to check but mine didn't have some of that magic numbers stuff and reflection.

Product Spotlight
Product Spotlight 

Community Advice: ASP | SQL | XML | Regular Expressions | Windows

©Copyright 1998-2024 ASPAlliance.com  |  Page Processed at 2024-04-14 1:37:16 AM  AspAlliance Recent Articles RSS Feed
About ASPAlliance | Newsgroups | Advertise | Authors | Email Lists | Feedback | Link To Us | Privacy | Search